AD-A222  376 


AFHRL-TP-90-1 0 


AIR  FORCE  ® 


CONTENT  DATA  MODEL:  TECHNICAL  SUMMARY 


Mark  Earl,  Captain,  USAF 
David  R.  Gunning 

LOGISTICS  AND  HUMAN  FACTORS  DIVISION 
Wright-Patterson  Air  Force  Base,  Ohio  45433-6503 


OTIC 


S 


ELECTE  l 
JUNO  5  1990  [ 


Eric  Freese 
Rona*d  Shroder 
Walter  Werts 
Tim  Reser 

RJO  Enterpriser,  Inc. 
101  Woodman  Drive 
Dayton,  Ohio  45431 


May  1990 

Final  Technical  Paper  for  Period  August  1985  -  January  1990 


Approved  for  public  release;  distribution  is  unlimited. 


LABORATORY 


AIR  FORCE  SYSTEMS  COMMAND 
BROOKS  AIR  FORCE  BASE,  TEXAS  78235-5601 


NOTICE 


When  Government  drawings,  specifications,  or  other  data  are  used  for  any  purpose 
other  than  in  connection  with  a  definitely  Government-related  procurement,  the 
United  States  Government  incurs  no  responsibility  or  any  obligation  whatsoever. 
The  fact  that  the  Govemmant  may  have  formulated  or  in  any  way  supplied  the  said 
drawings,  specifications,  or  other  data,  is  not  to  be  regarded  by  Implication,  or 
otherwise  in  any  manner  construed,  as  licensing  the  holder,  or  any  other  person  or 
corporation;  or  as  conveying  any  rights  or  permission  to  manufacture,  use,  or  sell 
any  patented  invention  that  may  in  any  way  be  related  thereto. 

The  Public  Affairs  Office  has  reviewed  this  paper,  and  it  is  releasable  to  the  National 
Technical  Infonnation  Service,  where  it  will  be  available  to  the  general  public, 
including  foreign  nationals. 

This  paper  has  been  reviewed  and  is  approved  for  publication. 


BRYAN  K.  CAPORLETTE,  2Lt,  USAF 
Contract  Monitor 


BERTRAM  W.  CREAM,  Technical  Director 
Logistics  and  Human  Factors  Division 


JAMES  C.  CLARK,  Colonel,  USAF 
Chief,  Logistics  and  Human  Factors  Division 


Content  Date  Model :  Technical  Su— ary 


AU 
Mark  Earl 
David  R.  Gunning 


Eric  Frits* 
Ronald  Shroder 


Wal  ter  Werts 
Tie  Reser 


C  •  F09603-87 -G-0659 
PE  -  631 06F 
PR  •  2950 
TA  -  00 
UU  -  08 


7.  PERFORMING  ORGANIXA TlON  NAME(S)  AND  AOORESStfS) 

RJO  Enterprises,  Incorporated 
101  Woodman  Drive 
Dayton,  Ohio  45431 


•.  PERFORMING  ORGANISATION 
REPORT  fVUMOE.R 


9.  SPONSORING/ MONITORING  AGENCY  NAM((S)  AND  AOORISS(tS) 

Logistics  and  Human  Factors  Division 
•Air  Force  Human  Resources  Laboratory 
Wright-Fatterson  Air  rnree  Base,  Ohio  45433-6503 


10.  SPONSORING.  MONITORING 
AGCNCf  REPORT  NUMtIR 


AFHRL-TP-90-1 0 


13a.  DISTRIBUTION /  A  YAiLABJUTY  STATEMIN 
Approved  for  public  release;  distribution  is  unlimited. 


2b.  DISTRIBUTION  COO* 


fURTTiiTTSI 


(Muhmum  ZOO  worrm 

^  Due  to  the  increasing  complexity  and  number  of  modem  weapon  sys tarns,  the  Air  Force  faces  an 
ever-growing  number  of  paper-based  technical  orders.  The  Air  Force  Human  Resources  Laboratory  has 
conducted  research  and  development  (R»)  of  automated  technical  Information  systems.  This  research 
investigated  technologies  for  the  storage,  distribution,  and  presentation  of  technical  information. 
Benefits  of  this  research  will  Include  Improvement  in  the  perform  nee  of  maintenance  personnel  and 
reduction  In  the  cost  of  maintaining  Air  Force  technical  information. 

One  of  the  products  of  this  RAO  includes  a  technology  which  provides  the  Air  Force  with  an 
economical  way  of  storing  and  presenting  technical  data.  The  Content  Data  Model  (CDM)  Is  a 
specification  for  a  data  base  which  is  intended  to  store  all  of  the  technical  Information  for  a  weapon 
system.  At  this  time,  the  CON  stores  only  maintenance  and  operational  information.  This  paper 

presents:  (a)  a  description  of  the  work  Involved  In  the  development  of  the  COM,  (b)  a  detailed 
description  of  the  COM,  (c)  efforts  to  demonstrate  and  validate  the.C0M,  and  (d)  the  development  of  a 
^c1f1c*t,on  for  thm  preparation  and  delivery  of  technical  data  in  CDM  format. 


14.  SUBJECT  TERM! 

computer-aided  acquisition  and  logistics  support  system  ( CALS )  ,  /^Va'  j  O — '  j  152 

content  data  model  standard  generalized  markup  language  1 11  WUCI  CODE 


IS.  SECURITY  CLASSIFICATION 

It.  SECURITY  CLASSIFICATION 

20.  LIMITATION  Of  ABSTRACT 

Of  THIS  RAGE 

of  abstract 

Unclassified 

Unclassified 

UL 

Standard  Form  299  (Rav.  2-9 9) 

HNbiilf 


NSN  -290-5500 


AFHRL  Technical  Paper  90-10 


May  1990 


CONTENT  DATA  MODEL  TECHNICAL  SUMMARY 


Mark  Earl,  Captain,  USAF 
David  R.  Gunning 

LOGISTICS  AND  HUMAN  FACTORS  DIVISION 
Wright-Patterson  Air  Force  Base,  Ohio  45433-6503 


Eric  Freese 
Ronald  Shroder 
Walter  Werts 
Tim  Reser 

ftJO  Enterprises,  Inc. 
101  Woodman  Drive 
Dayton,  Ohio  45431 


Reviewed  by 

Robert  C.  Johnson 
Chief,  Combat  Logistics  Branch 


L  Accesio"1  For  j 

NT)$ 

CHAil 

one 

TAB 

□ 

Unannounced 

□ 

J.iSliflt. 

Jt.t  *n 

By 

jlnbul-O*'  / 

A 

.•  .1  '1,  »ty|  •  1  y 

Disl 

A  sdil  -j1 
Sy*". 

vl  /  or 
wl 

A-/ 

Submitted  for  publication  by 

Bertram  W.  Cream,  Technical  Director 
.  Logis  nd  Human  Factors  Division 


This  publication  is  primarily  a  working  paper.  It  is  published  soley  to  document  work  performed. 


SUMMARY 


Due  to  the  increasing  complexity  and  number  of  modem  weapon  systems,  the  Air 
Force  faces  an  ever  growing  number  of  paper-based  technical  orders.  The  Air  Force 
Human  Resources  Laboratory  has  conducted  research  and  development  of  automated 
technical  information  systems.  This  research  investigated  technologies  for  the  storage, 
distribution,  and  presentation  of  technical  information.  Benefits  of  this  research  will 
include  improvement  of  performance  of  maintenance  personnel  and  reduction  in  cost  of 
maintaining  Air  Force  technical  information. 

One  of  the  products  of  this  research  includes  a  technology  which  provides  the  Air 
Force  with  an  economical  way  of  storing  and  presenting  technical  data.  1116  Content  Data 
Model  (CDM)  is  a  specification  for  a  data  base  which  is  intended  to  store  all  of  the 
technical  information  for  a  weapon  system.  At  this  time,  the  CDM  stores  only 
maintenance  and  operational  information.  The  CDM  will  facilitate  the  interchange  of 
technical  information  between  contractors  and  the  government. 

This  paper  presents. 

•  A  description  of  the  work  involved  in  the  development  of  the  CDM. 

•  A  detailed  oescription  of  the  CDM. 

•  Efforts  to  demonstrate  and  validate  the  CDM. 

•  The  development  of  a  draft  specification  for  the  preparation  and  delivery  of 
technical  data  in  CDM  format. 


PREFACE 


The  work  described  in  this  paper  was  performed  in  support  of  the  Computer-Aided 
Acquisition  and  Logistic  Support  initiative  of  the  Air  Force  Systems  Command.  This 
work  is  consistent  with  the  Air  Force  Human  Resources  Laboratory,  (AFHRL)  Logistics 
and  Human  Factors  Division’s  Mission  to  improve  the  combat  maintenance  capability  and 
readiness  of  the  Air  Force. 

The  work  described  in  this  paper  was  performed  by  the  Air  Force  Human  Resources 
Laboratory,  RJO  Enterprises.  Inc.,  and  Datalogics,  Inc.  The  RJO  effort  was  conducted 
under  contract  #F09603-87-G-0659/SG02;  the  Datalogic’s  work  was  performed  under 
subcontract  to  RJO.  Captain  Mark  J.  Earl,  AFHRL  Combat  Logistics  Branch  (LRC); 
served  as  the  laboratory  technical  monitor  and  the  contracting  officer’s  technical 
representative  (COTR)  for  the  effort.  Major  contributors  to  this  effort  included  Mr.  David 
Gunning  (AFHRL)  and  Major  Paul  Condit  Air  Force  Logistics  Command  (AFLC). 
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THE  CONTENT  DATA  MODEL: 
TECHNICAL  SUMMARY 

1.  INTRODUCTION 


Currently  a  number  of  separate  technical  manuals  are  required  to  support  a  system 
or  subsystem.  Each  manual  is  designed  to  support  specific  maintenance  functions  and 
contains  the  information  required  to  accomplish  those  actions.  Examination  of  the 
manuals  for  typical  system  reveals  that,  in  many  instances,  a  given  piece  of  information 
occurs  in  more  than  one  manual  and  sometimes  several  times  in  the  same  manual.  For 
example,  a  warning  may  apply  to  several  maintenance  actions  and  appear  in  several 
manuals  or  several  times  in  the  same  manual  (see  Figure  1).  This  redundancy  is 
inevitable  in  a  paper  based  system.  However,  the  use  of  a  fully  digital  technical  data 
system  will  provide  a  means  of  eliminating  this  unnecessary  redundancy  and  greatly 
reduce  storage  requirements,  simplify  the  update  process,  and  insure  more  up  to  date 
technical  data.  The  use  of  a  fully  integrated  data  base  that  contains  all  of  the  technical 
information  required  to  maintain  a  system  will  make  this  possible.  The  integrated  data 
base  will  store  each  piece  of  information  once.  Then,  when  a  procedure  is  called  which 
uses  that  information,  the  information  is  extracted  from  the  data  base  and  combined  with 
other  elements  of  information  to  construct  the  exact  information  (e.g..  a  step-by-step 
procedure)  for  presentation  on  a  computer  display  or  for  printing  on  paper  as  needed. 
This  paper  describes  a  research  effort  conducted  by  the  Air  Force  Human  Resources 
Laboratory  to  develop  and  test  a  model  of  an  integrated  data  base  to  accomplish  this 
objective.  The  model  developed  is  known  as  the  Content  Data  Model  (CDM).  The 
development  and  validation  of  the  CDM  is  described  in  the  following  sections. 

Objective 

The  basic  objective  of  this  effort  was  to  develop  and  validate  a  model  of  an 
integrated  data  base  to  maintain  technical  data  to  support  maintenance  operations. 
Specific  objectives  of  the  effort  were  to: 

1.  Design  and  develop  the  integrated  data  base  model  (the  CDM). 

2.  Analyze  technical  data  requirements  and  compare  the  results  of  the  analysis 
with  the  CDM  to  insure  that  the  CDM  adequately  supports  all  technical 
information  requirements. 

3.  Compare  the  CDM  with  exiting  technical  information  systems  and  standards  to 
insure  compatibility. 

4.  Develop  a  specification  defining  requirements  for  technical  data  developed  for 
use  with  the  CDM. 

5.  Validate  the  CDM  specification  by  designing  and  building  a  data  base, 
populating  the  data  base  with  sample  data,  and  extracting  the  data  for 
presentation  in  different  formats  on  different  media. 

II.  BACKGROUND 

In  order  to  support  the  CALS  initiative,  several  organizations  within  the  DoD  and 
industry  conducted  efforts  to  develop  technical  information  development  and  delivery 
systems.  These  groups  included  AFHRL,  the  Air  Force  Logistics  Command  (AFLC),  the 
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Navy,  the  Army,  and,  Northrop  Corporation,  the  prime  contractor  for  the  B-2  bomber. 
This  section  highlights  the  efforts  undertaken  by  AFHRL  and  provides  a  background  to 
the  development  of  the  CDM.  Also  examined  are  three  relevant  forerunners  of  the  CDM: 
Automated  Technical  Order  System  (ATOS),  Improved  Technical  Data  System  (ilDS), 
and  MIL-M-28001. 


CURRENT  PAPER-BASED  SYSTEM 

STORES  SAME 
INFORMATION  MANY  TIMES 


Job  Guide 


DATABASE  SYSTEM 

STORES  INFORMATION 
ONLY  ONCE 


Figure  1.  Reduction  of  Storage  Requirements. 


AEHBL  ActivUtes 

In  1976,  AFHRL  began  conducting  research  and  development  (R&D)  of  automated 
technical  information  systems  to  support  aircraft  maintenance  technicians.  This  R&D 
investigated  technologies  for  the  storage,  distribution  and  presentation  of  technical 
information  using  automated  systems.  The  research  was  done  to  improve  the 
performance  and  productivity  of  maintenance  personnel  and  to  reduce  the  cost  of 
maintaining  Air  Force  technical  information.  The  research  has  progressed  through  four 
increments  (see  Figure  2): 

1.  Computer-Based  Maintenance  Aiding  System,  which  tested  information 
presentation  and  human-computer  interaction  techniques. 

2.  Authoring  and  Presentation  System,  which  refined  the  definition  of  data 
elements  as  well  as  providing  a  means  for  authoring  and  presenting  technical 
information. 

3.  Integrated  Data  Base,  which  was  designed  to  store  all  of  the  information  for  a 
particular  weapon  system. 
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4.  Content  Data  Model,  which  facilitates  the  interchange  of  technical  information 
and  provides  a  structure  for  the  storage  of  technical  information. 


Figure  2.  Related  AFHRL  Activities. 

ConiButtCrBassd  Main.ts.na,p$s  Aid  in*  .System 

AFHRL  developed  the  Computer-Based  Maintenance  Aiding  System  (CMAS)  to 
evaluate  integrated  information  presentation  and  human/computer  interface  techniques 
for  technical  information.'  The  CMAS  systems  also  allowed  investigation  into  the  use  of 
digital  technical  information  under  controlled  field  conditions.  Specific  concepts 
evaluated  included  multiple  levels  of  detail,  various  facilities  for  accessing  technical 
manual  data,  presentation  of  diagrams  larger  than  the  screen,  function  key  utility, 
human/computer  interaction,  and  presentation  of  troubleshooting  procedures. 

Two  prototype  systems  for  intermediate  level  maintenance  were  developed  under  the 
CMAS  program.  Among  the  many  lessons  learned  from  the  project  was  that  a  more 
efficient  means  of  developing  the  technical  data  to  be  presented  on  an  automated  system 
was  required.  The  process  of  developing  technical  information  for  the  prototypes 
required  the  use  of  complex  codes  to  control  the  retrieval  and  presentation  of  the  data. 
Technical  data  authors  were  required  to  input  these  complex  codes  by  hand  with  only 
limited  assistance  from  authoring  aids.  The  result  was  that  the  creation  of  the  data  was 
expensive,  and  the  data  contained  many  system  control  code  errors.  .Also,  the  technical 
data  and  technical  data  presentation  software  developed  for  CMAS  was  operational  on 
only  one  computer  system.  This  highlighted  the  necessity  of  designing  a  data  base  which 
would  not  be  limited  to  use  on  one  system.  These  observations,  along  with  similar 
concerns  expressed  by  AFHRL  personnel  working  in  support  of  the  AFLC  Automated 
Technical  Order  System  (ATOS),  led  to  a  decision  to  investigate  the  storage  of  technical 
information  in  a  data  base. 

A  contract  with  Rockwell  was  modified  to  include  a  requirement  to  conduct  an 
analysis  of  the  data  base  requirements  and  to  develop  a  coding  scheme  for  preparing  data 
for  storage  in  a  “neutral"  data  base.  Neutral  data  is  designed  so  that  it  can  be  presented 
on  any  computer.  The  preliminary  study  performed  by  Rockwell  included  a  detailed 
analysis  of  the  Air  Force  specifications  for  intermediate  level  technical  data.  The  analysis 
of  the  data  identified  each  element  of  data  and  the  characteristics  of  each  element.-  The 
characteristics  (or  attributes)  were  then  categorized  according  to  elements  with  common 
attributes.  These  categories  provided  the  necessary  source  information  for  the 
development  of  a  preliminary  data  base  design.  The  design  (or  coding  scheme)  was 
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developed  under  subcontract  by  Datalogics,  Inc.  It  was  based  upon  the  Standard 
Generalized  Markup  Language  (SGML)  which  was  also  being  used  in  the  ATOS  program. 
SGML  was  selected  as  a  starting  point  to  ensure  data  base  compatibility  with  ATOS.  The 
SGML  coding  scheme  labels  each  element  of  data  (e.g.,  a  paragraph,  part  number,  or 
title)  with  an  identifier  specifying  the  type  of  information  and  relationships  to  other  data 
elements.  For  example,  a  paragraph  may  have  codes  specifying  the  chapter  it  belongs  to, 
the  preceding  paragraph,  or  an  illustration  which  accompanies  the  paragraph. 

Once  the  technical  information,  with  its  corresponding  codes,  is  developed  and 
stored,  it  can  be  formatted  for  printing  or  for  display  on  a  computer  monitor.  Special 
software  formats  the  data  according  to  th<;  characteristics  of  the  specific  display  device 
and  predefined  formatting  rules.  For  example,  if  a  data  element  is  a  header  element, 
presentation  (or  printing)  of  the  data  will  occur  in  the  location  on  the  display  (or  page) 
specified  by  the  formatting  rules  and  display  (or  page)  characteristics.  This  approach 
makes  it  possible  to  display  technical  data  on  a  variety  of  systems  without  modification  to 
the  data  base.  It  also  makes  it  possible  to  print  the  data,  if  desired,  or  use  it  in  other  ways 
without  modifying  the  data  base. 

Authoring  and  Presentation  System 

The  results  of  the  analysis  and  coding  specification  provided  the  starting  point  for  an 
AFHRL  in-house  effort  to”  develop  an  efficient  means  of  developing  data  in  a  neutral 
format  for  presentation  on  a  variety  of  systems.  The  primary  objectives  of  this  new  effort 
were  to  extend  and  refine  the  set  of  identified  data  elements  and  to  develop  software  for  a 
system  to  author  and  present  technical  data  using  a  neutral  data  base.  The  Authoring  and 
Presentation  System  (APS)  effort  developed  a  neutral  data  base  which  could  be  presented 
on  various  displays  and  printed  according  to  specified  formats  without  requiring  changes 
in  the  data  base  (See  Figure  3). 

The  Authoring  and  Presentation  System  effort  developed  software  to  provide  an 
efficient  means  of  creating  the  data  with  the  requirement  for  the  neutral  data  base  and 
software  to  present  the  date  on  various  computer  systems. 

The  design  of  the  APS  data  bases  was  initially  based  on  paper  technical  data. 
Instead  of  duplicating  the  structure  of  the  current  technical  order  system,  a  data  design 
and  data  base  approach  designed  primarily  for  use  by  electronic  applications  was 
developed. 

The  authoring  portion  of  the  system  allowed  a  technical  manual  author  to  create  data 
as  if  the  writer  were  using  a  standard  word  processing  system.  Using  this  part  of  the 
system,  the  author  could 

1.  create  or  modify  data. 

2.  attach  attributes  (e.g.,  this  is  a  paragraph). 

3.  link  supporting  information  to  the  data. 

Document  variations  and  configuration  control  were  also  maintained.  .This  allowed  the 
author  to  maintain  many  versions  of  a  document  from  within  the  same  data  base.  The 
presentation  portion  of  APS  displayed  only  the  information  needed  by  a  particular 
maintenance  technician  for  the  particular  aircraft  and  the  specific  task  on  which  the 
technician  was  working. 
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Figure  3.  Present  and  Future  Display  Technologies. 

APS  provided  a  way  to  author  and  present  data  in  a  neutral  format.  However,  each 
different  Technical  Order  (TO)  had  its  own  data  base  resulting  in  redundancy  of  data 
since  information  used  in  several  TOs  was  repeated  in  each  Technical  Order.  The 
concept  of  an  integrated  data  base  was  developed  to  model  all  of  the  technical 
information  for  a  weapon  system  in  a  single  neutral  data  base  while  removing  the 
redundant  data. 


Integrated  Data  .Base  Design 


The  integrated  technical  information  data  base  contains  all  of  the  information  for  a 
particular  weapon  system.  While  APS  stored  technical  information  manual  by  manual, 
the  integrated  data  base  stores  many  manuals  in  a  single  data  base.  Such  a  datr.  base  is 
considered  integrated  because  different  types  of  information  (i.e.,  organizational, 
intermediate,  depot)  found  in  different  manuals  can  be  stored  within  the  one  data  base. 
The  information  within  the  data  base  can  be  cross-referenced  similar  to  the  way  in  which 
cross-references  are  made  in  the  present  manuals.  For  example,  if  in  the  process  of 
doing  a  fault  isolation  procedure  a  reference  is  made  to  a  job  guide  procedure,  the 
technician  using  the  current  paper  TOs  would  have  to  find  the  correct  job  guide  manual, 
complete  the  procedure,  and  then  return  to  the  fault  isolation  manual.  The  same 
technician  accessing  the  data  from  the  integrated  data  base  would  be  able  to  access  the 
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information  automatically.  Once  the  job  guide  procedure  has  been  completed,  the 
technician  would  be  automatically  returned  to  the  same  place  in  the  fault  isolation 
procedure  and  continue  working. 

Each  piece  of  technical  information  consists  of  three  items:  a)  content,  b)  structure, 
and  c)  format  (see  Figure  4).  Content  is  the  actual  information  which  is  presented.  The 
content  of  the  information  is  interpreted  by  the  reader  as  it  is  accessed.  Structure  consists 
of  the  organization  of  the  technical  information  and  sequence  in  which  the  technical 
information  will  be  displayed.  For  example,  a  task  in  a  technical  manual  consists  of 
steps,  illustrations,  warnings,  notes,  cautions,  etc.  The  technical  information  within  a 
technical  manual  may  be  sequenced  in  a  specific  order  such  as  an  introduction  followed 
by  the  steps  with  warnings,  notes,  and  cautions  where  appropriate.  Format  is  the. 
appearance  and  style  on  the  displayed  information.  For  example,  numbers  may  be  added 
to  the  steps  or  a  warning  may  be  labelled  with  the  word  “warning”  within  a  box  which  is 
centered  on  the  page. 

Data  for  presentation  on  automated  technical  data  systems  may  be  stored  with  or 
without  formatting  information.  It  is  more  efficient  to  store  the  data  without  formatting 
for  two  reasons:  a)  data  with  formatting  information  can  only  be  presented  on  specific 
computers,  and  b)  formatted  data  must  be  stored  with  its  unique  format  requirements 
every  time  it  is  used  creating  redundancy.  The  use  of  an  integrated  data  base  with 
neutral,  unformatted  data  overcomes  both  problems.  The  data  is  stored  only  once  no 
matter  how  many  times  it  may  be  used.  For  example,  a  warning  may  be  stored  only  once 
even  though  it  is  used  in  many  procedures. 

The  data  bases  of  technical  information  will  also  be  easier  to  maintain  than  the 
present  technical  order  libraries.  Required  changes  and  updates  can  be  quickly 
incorporated  into  the  main  data  base  since  the  data  is  stored  once.  This  ensures  that  the 
users  have  access  to  the  most  accurate  information  available. 

Contcnt-Pata-Modd  .(CBM1 

The  requirement  for  a  neutral,  integrated  data  base  resulted  in  the  development  of 
the  CDM.  The  CDM  is  a  model  for  the  interchange  of  integrated  data  bases  of  technical 
information. 

Data  developed  using  the  CDM  structure  will 

1 .  allow  efficient  interchange  between  contractors  and  the  government  of  technical 
information. 

2.  allow  quick  and  efficient  presentation  of  the  information  on  any  current  or 
future  display  medium. 

3.  eliminate  redundant  data,  thus  reducing  data  storage  requirements. 

4.  allow  rapid  updating  of  the  data  as  technical  changes  are  implemented. 

5  eliminate  the  need  to  change  the  data  due  to  changes  in  the  formatting 
requirements  of  the  presentation  system. 
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STRUCTURE 


-  STEP  2  (#12) 
FOLLOWS  STEP  X 
(#11) 

-  WARNING  Y 
PRECEDES  STEP  Z 

(#12) 


FORMAT 

-  BOX  AROUND  WORD 
“WARNING'.  ALL 
CAPS.  CENTERED 

-  NUMBER  STEPS 
SEQUENTIALLY 


CONTENT 
-  ACTUAL  TEXT 


Figure  4.  Content,  Structure,  and  Format. 

Other  Related  Efforts 

While  AFHRL  was  conducting  their  research,  other  groups  within  the  government 
and  industry  were  developing  their  own  strategies  for  the  development  and  presentation  of 
digital  technical  information. 

Automated  Technical  Order  System  fATQSI 

The  ATOS  program  was  sponsored  by  the  Air  Force  Logistics  Command  (AFLC). 
Its  intent  was  to  automate  the  capture,  storage,  and  maintenance  of  page-oriented 
technical  order  data.  It  would  also  automate  the  distribution,  management,  and 
presentation  of  page-oriented  technical  order  data. 

ATOS  gathered  data  from  contractors  and  material  management  offices.  ATOS  also 
supplied  technical  orders  for  maintenance,  repair,  inspection,  and  modification  functions. 
This  provided  for  the  productive  coexist-. nee  of  both  the  automated  and  manual  technical 
order  systems  and  allowed  for  the  reduction  and  eventual  elimination  of  manual  technical 


7 


order  maintenance  and  distribution.  The  ATOS  program  was  replaced  by'  the  Air  Force 
Technical  Order  Management  System  (AFTOMS)  program. 

Improved  Technical  Data  System  (TIPS'! 

Improved  Technical  Data  System  (ITDS)  is  an  interactive  information  delivery 
system  developed  by  Northrop  Corporation  for  the  B-2  program.  It  supports  the 
presentation  of  technical  data  to  users  engaged  in  the  operation,  maintenance,  training, 
and  support  of  equipment  and  systems.  ITDS  models  technical  data  as  a  linear  stream  of 
information  with  Standard  Generalized  Markup  Langjage  (SGML)  commands  embedded 
within  text  and  tabular  data.  Tne  SGML  markup  codes  identify  the  type  of  the  technical 
data  and  specifies  formatting  instructions  such  as  sizing,  positioning,  and  color  for 
electronic  display  or  paper  printing  of  the  technical  data.  Through  the  use  of  SGML 
Document  Type  Definitions  (DTDs),  an  application  can  rigorously  define  a  class  of 
documents  such  as  job  guides,  flight  manuals,  and  fault  isolation  procedures  and  prepare 
them  for  output. 

MIL-M-28001 


MIL-M-28001  is  a  military  specification  which  defines  the  requirements  for  the 
digital  textual  data  form  of  technical  publications.  Data  prepared  in  conformance  to  the 
requirements  in  this  specification  facilitates  automated  preparation,  storage,  retrieval, 
exchange,  and  processing  of  technical  documents.  The  requirements  set  forth  by  this 
specification  include 


1.  procedures  and  symbols  for  markup  of  unformatted  text  in  accordance  with  the 
military’s  specific  application  of  SGML. 

2.  SGML  compatible  codes  that  will  allow  a  technical  publication  to  conform  to 
specific  content,  structure  and  format  requirements  including  MIL-M-38784  as 
applicable  to  technical  manuals. 

3.  output  controls  that  will  provide  a  uniform  structure  for  automated  document 
processing  functions. 


Under  theCALS  initiative,  MEL-STD-1840  specifies  the  delivery  of  digital  technical 
information.  The  standard  references  a  group  of  military  specifications  which  specify  the 
delivery  requirements  for  certain  types  of  data.  Textual  technical  information  must 
maintain  compatibility  with  MIL-M-28001  by  using  SGML  as  the  specification  language. 
Graphical  technical  information  developed  on  computer-aided  design  (CAD)  systems 
must  adhere  to  MIL-D-28000  or  MIL-D-28003.  Graphical  technical  information  entered 
using  electronic  scanning  equipment  must  conform  to  MIL-R-28002  (see  Figure  5). 

Standard  Generalized  Markup  Language 


SGML  was  used  in  the  development  of  the  CDM  for  several  reasons:  (a)  CDM 

m?t  m  iwk?crKrchan^d  t0  thc  government  and  among  contractors  under 
j001,  ?)  ,S  .  Provides  a  checkable  syntax  so  automated  validation  testing 
2"  done*  and  (°)  s,nce  storage  of  the  data  occurs  in  ASCII  text  files,  each  application 
n’ay.use  different  data  base  management  systems  on  different  hardware 
systems  and  still  be  able  to  exchange  and  update  data  from  other  sources. 

The  International  Standards  Organization  (ISO)  developed  SGML  as  an  efficient  way 

[ang.  °!  documents  between  different  types  of  computers.  Used 
internationally,  SGML  breaks  documents  into  text  pieces  using  a  standard  set  of  markup 
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codes.  The  different  markup  codes  describe  the  structure  of  the  document.  The  SGML 
markup  codes,  also  called  “tags”,  are  used  to  map  the  document.  The  SGML  markup 
codes  do  not  describe  output  formatting  information. 


Figure  5.  MIL-STD-1840  and  Associated  Specifications. 


The  SGML  declaration  defines  syntax  rules  for  the  SGML  tagging  process.  It  defines 

1.  the  actual  characters  used  to  distinguish  tags  from  regular  words  within  the 
document. 


2.  the  limits  for  tag  lengths. 


3.  whether  tags  will  be  in  upper  or  lower  case. 


A  common  syntax  which  is  applicable  for  most  documents  is  defined  in  the 
ISO-8879-1986  standard  for  SGML. 

The  Document  Type  Definition  (DTD)  defines  the  grammar  of  the  tag  language  used 
within  a  document.  The  grammar  specifies  the  names  of  the  tags  being  used  and  their 
possible  position  within  a  document.  Each  different  type  of  document  will  probably  have 
a  different  DTD.  In  order  to  further  explain  SGML,  an  inter-office  memo  will  be  used. 

Some  companies  have  policies  for  the  information  contained  in  a  memo  and  the 
organization  of  a  memo.  For  example,  a  memo  may  have  a  sender,  a  receiver,  the  date 
of  the  memo,  and  the  subject  of  the  memo.  It  would  also  contain  paragraphs  of  text.  A 
memo  may  also  have  attachments.  A  possible  outline  of  the  structure  for  the  memo  is 
shown  in  Figure  6. 
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I.  MEMO 

A.  Header 

1 .  Receiver 

2.  Sender 

3.  Date 

4.  Subject 

B.  Body 

1 .  Paragraphs 

C.  Attachments 

Figure  6.  Structure  of  a  Sample  Memorandum. 

The  outline  provides  the  structure  of  the  memo.  Using  this  structure  the  content  may  be 

entered  as  shown  in  Figure  7. 


RECEIVER: 

All  Employees 

SENDER: 

John  Doe 

DATE: 

June  7,  1987 

SUBJECT: 

Memorandum  Formats  (Policy  158-87) 

PARAGRAPH: 

In  order  to  improve  the  flow  of  information  throughout  the  company,  a  standard 
memorandum  format  is  being  adopted. 

PARAGRAPH: 

Every  memo  must  have  the  heading  which  will  include  an  addressee,  a  sender,  a 
date,  and  the  subject  of  the  memo.  The  body  of  the  memo  will  contain  the  actual 
text.  Attachments  may  be  made  to  the  memo.  If  there  are  attachments,  it  must  be 
noted  on  the  memo. 

Figure  7.  Content  of  a  Sample  Memorandum. 
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In  order  to  produce  memos  intended  for  the  receivers,  the  memo  needs  rules  which  define 
the  display  of  the  information  (see  Figure  8).  In  this  example,  the  memo  will  be  printed 
on  paper. 

Receiver  will  be  printed  on  the  first  line,  left  justified,  preceded  by  the  label,  uTO:tt. 

Date  wilt  be  printed  on  the  first  line,  right  justified,  with  no  label. 

Sender  will  be  printed  on  the  third  line,  left  justified,  preceded  by  the  label, 
“FROM". 

Subject  will  be  printed  on  the  fifth  line,  left  justified,  preceded  by  the  label,  “RE:". 

Paragraphs  will  begin  two  lines  below  the  last  line  printed.  The  first  line  of  the 
paragraph  will  be  indented  five  spaces. 

If  there  are  attachments  to  the  memo,  the  word,  "Enclosures"  will  be  printed  three 
lines  below  the  last  line  printed. 

Figure  8.  Format  Rules  for  a  Sample  Memorandum. 

When  the  content  of  the  memo  is  organized  based  on  the  structure  and  printed  using 
the  format  rules,  the  output  will  appear  as  shown  in  Figure  9. 

ADDRESSEES  ✓  DATE 

s 

SENDER 
SUBJECT'-,., 

PARAGRAPH  — 

PARAGRAPH  — 

ATTACHMENT', 

Figure  9.  Sample  Memorandum. 


TO;  All  Employees 

FROM:  John  Doe 


June  7,  1987 


RE:  Memorandum  Formats  (Policy  No.  158-87) 

In  order  to  improve  the  flow  of  information  throughout  the 
company,  a  standard  memorandum  format  is  being 
.adopted. 

Every  memo  must  have  the  heading  which  will  include  an 
addressee,  a  sender,  a  date,  and  the  subject  of  the 
memo.  The  body  of  the  memo  will  contain  the  actual 
text.  Attachments  may  bu  made  to  the  memo.  If  there 
.are  attachments,  it  must  be  noted  on  the  memo. 


Enclosures 
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Using  ,  s  structure  defined  above,  the  SGML  DTD  for  the  memo  may  appear  as  shown  in 
Figure  10. 


<!DOCTYPE  memo  [ 

<!ENTITY  %  text 

"(#PCDATA)"  > 

<!  ELEMENT  memo 

-  - 

(header,  body,  attach)  > 

<!ELEMENT  header 

— 

(to,  from,  date,  subject)> 

<!  ELEMENT  to 

-  0 

%text;  > 

<!ELEMENT  from 

-  0 

%text;  > 

<!ELEMENT  date 

-  0 

%text;  > 

<!ELEMENT  subject 

-  0 

%text;  > 

<!  ELEMENT  body 

— 

(para)*  > 

<!EIJEMENT  para 

-  0 

%text;  > 

<!ATTLIST  para  number  NUMBER  /^REQUIRED  > 

<!ELEMENT  attach 

-  0 

EMPTY  > 

<!ATTLIST  attach 

yesomo  CDATA  ’no’  > 

1> 

Figure  10.  DTD  for  Sample  Memorandum. 

As  mentioned  before,  the  DTD  defines  the  names  of  the  tags  which  label  the 
different  data  items.  The  DTD  also  defines  the  structure  of  the  data. 

A  DTD  consists  of  a  document  type  (doctype),  entities,  elements,  and  attributes. 
The  doctype  simply  gives  a  name  to  the  DTD.  In  this  example,  “memo”  is  the  name  of 
the  DTD. 

An  entity  is  an  abbreviation  or  substitution  mechanism.  An  entity  declaration 
consists  of  a  a  name  for  the  entity,  and  a  text  string  surrounded  by  quotes.  Any 
time  an  entity  occurs  within  the  element  or  attribute  declarations,  the  text  is  automatically 
inserted  where  the  entity  name  occurs.  For  example,  the  line, 

<!ELEMENT  subject  -  o  %text;  > 

would  look  like, 

c.'ELEMENT  subject  .-  o  (#PCDATA)  > 
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after  the  substitution.  This  allows  the  DTD  developer  to  define  items  which  may  appear 
many  times  in  the  DTD  as  a  single  entity. 

An  element  is  a  piece  of  data  within  a  document.  Within  the  element  declaration,  a 
name  for  the  element  is  defined.  Following  the  name,  the  DTD  developer  sets  the 
requirements  for  beginning  and  ending  tags.  The  beginning  tag  marks  the  beginning  of  a 
piece  of  data.  For  example,  the  beginning  tag  for  a  header  would  be  entered  as: 
<header>.  The  ending  tag  marks  the  end  of  a  piece  of  data.  A  signifies  the 
requirement  for  an  end  tag.  A  uo"  signifies  that  the  tag  is  optional.  For  example,  the 
ending  tag  for  a  header  would  be  entered  as:  </header>.  Next,  the  structure  of  the 
element  is  defined.  An  element  may  be  made  up  of  other  elemerits,  or  it  may  contain 
actual  data. 

<!ELEMBNT  header  -  -  (to,  from,  date,  subject)> 

<!ELEMENT  to  -  o  %text;  > 

In  the  example  above,  the  “header”  element  must  have  beginning  and  ending  tags.  It  is 
made  up  of  “to,”  “from,”  “date,"  and  “subject"  information.  The  “to”  element  must 
have  a  beginning  tag,  but  an  ending  tag  is  optional.  The  element  definition  includes  the 
“text”  entity  which  can  be  substituted  for  “#PCDATA"  which  is  an  SGML  term  for 
character  data. 

SGML  also  provides  a  mechanism  for  multiple  occurrences  of  an  element  within 
another  element.  Occurrence  indicators  define  these  special  cases.  A  “?"  signifies  that 
an  element  may  occur  zero  or  one  time.  A  “*"  signifies  that  an  element  may  occur  zero 
or  many  times.  A  “+"  signifies  that  an  element  may  occur  one  or  many  times. 

<!ELEMENT  body  -  -  (para)*  > 

In  the  example  above,  there  may  be  many  “para”  elements  within  a  body,  or  there  may 
be  none,  depending  on  the  application. 

Elements  may  have  attributes  associated  with  them.  An  attribute  is  a  characteristic 
or  property  which  does  not  contain  actual  content. 

clELEMENT  para  -  o  %text;  > 

<!/.~TLIST  para  number  NUMBER  ^REQUIRED  > 

In  the  example  above,  the  “para"  element  also  has  an  attribute  called  “number."  This 
attribute  defines  a  number  each  time  the  element  is  defined  because  the  DTD  designer 
has  designated  it  as  a  required  attribute. 

Using  the  SGML  markup  codes  described  in  the  DTD,  the  user  marks  up  or  “tags"  a 
document.  An  “instance"  of  a  document  is  a  marked  up  SGML  document.  The  memo 
tagged  using  the  DTD  in  Figure  10  is  shown  in  Figure  11. 

The  tags  define  the  content  and  the  structure  of  the  memo.  For  example,  everything 
located  between  the  “<header>”  beginning  tag  and  the  “</header>”  ending  tag  is  header 
information.  Also,  notice  the  definition  of  the  “number”  attribute  each  time  a  “para” 
element  was  defined. 

Computer  programs,  called  parsers,  check  the  DTD  and  the  document  instance.  A 
DTD  parser  checks  the  DTD  for  correct  and  complete  syntax.  A  document  instance 
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parser  checks  a  tagged  document  for  correct  and  complete  tagging  based  on  the 
document’s  DTD. 


<memo> 

<header> 

<to>  All  Employees 
<from>  Jonn  Doe 
<date>  June  7,  1987 

«subject>  Memorandum  Formats  (Policy  No.  158-87) 

</header> 

<body> 

<para  number  ■  “1”>  In  order  to  improve  the  flow  of  information  throughout  the 
company,  a  standard  memorandum  format  is  being  adopted. 

<para  number  ■  “2">  Every  memo  must  have  the  heading  which  will  include  an 
addressee,  a  sender,  a  date,  and  the  subject  of  the  memo.  The  body  of  the  memo 
will  contain  the  actual  text.  Attachments  may  be  made  to  the  memo.  If  there  are 
attachments,  it  must  be  noted  on  the  memo. 

</body> 

<attach  yesomo-”yes”> 

</memo> 

Figure  11.  Tagged  Sample  Memorandum. 

III.  CONTENT  DATA  MODEL 

The  CDM  is  the  proposed  model  for  an  integrated  weapon  system  data  base  intended 
to  meet  the  long  term  needs  of  the  DoD.  CDM  data  emphasizes  the  identification  of  the 
content  and  the  interrelationships  (or  structure)  between  data  elements  found  within 
technical  information. 


CBM-Concept 

The  CDM  is  a  definition  of  interrelated  technical  information.  This  definition 
describes  the  technical  information  using  its  content  and  structure.  Emphasis  is  not  on 
the  display  of  the  data  but  on  the  data  interrelationships  and  where  the  data  fits  together 
within  a  system.  Many  applications  can  use  the  data  without  modification.  The  CDM 


design  does  not  concern  itself  with  a  particular  output  display.  Since  the  information  does 
not  contain  format,  the  information  can  be  used  with  any  output  device  such  as  paper 
systems,  video  displays  and  future  technologies. 

For  example,  a  selected  subset  of  CDM  data  can  produce  a  particular  manual  and 
send  it  to  an  output  device.  Another  subset  of  the  data  required  to  support  interactive 
diagnostics  for  a  particular  subsystem  can  also  be  extracted  and  loaded  into  a  device  such 
as  a  portable  flight-line  computer.  This  will  save  money  by  cutting  waste,  reducing 
storage  space,  and  minimizing  updating  requirements.  . 

The  connections  between  elements  identified  within  the  CDM  facilitate  integration  of 
the  data.  Data  can  be  created  in  many  ways  and  then  loaded  into  the  CDM.  Once  in 
CDM  form,  the  content  and  structure  of  the  data  is  preserved.  Subsets  of  the  CDM  can 
then  be  extracted,  converted,  manipulated,  and  displayed  on  different  devices  to  support  a 
variety  of  objectives. 


CDM  IteK.rlc.tian 

The  development  of  the  CDM  has  been  an  evolutionary  process.  Originally,  the 
structure  of  the  CDM  followed  the  structure  of  the  information  found  within  the  technical 
manuals.  However,  after  initial  demonstration  and  validation  efforts,  the  structure  was 
revised  in  order  to  more  accurately  model  all  of  the  technical  information  available  for  a 
weapon  system. 

The  revised  CDM  attempted  to  more  closely  model  the  actual  structure  of  technical 
information  within  the  Air  Force  (see  Appendix  A).  A  hierarchy  was  established  which 
described  the  weapon  system  and  the  corresponding  information  associateo  with  a 
specific  element  within  the  weapon  system. 

Within  this  hierarchy,  a  weapon  system  consists  of  smaller  systems,  which  consist  of 
subsystems,  which  consist  of  subassemblies,  which  finally  consist  of  individual  parts.  The 
CDM  models  the  technical  information  in  this  manner  (sec  Figure  12).  Information 
including  tasks,  descriptions,  and  trouble-shooting  procedures  connects  to  the  weapon 
system  at  the  level  in  which  the  information  is  used.  For  example,  tasks  and  descriptive 
information  which  speak  specifically  about  the  M61  automatic  gun  system  on  an  F-15 
connect  to  the  gun  system  while  more  general  information  may  connect  to  weapons 
system  or  to  the  aircraft  as  a  whole. 

Although  the  CDM  is  modelled  in  SGML,  the  physical  storage  of  the  data  base  it 
defines  could  vary  from  application  to  application.  Sequentially  tagged  ASCII  data  is 
suited  for  very  few  applications.  However,  the  ASCII  data  can  be  input  into  any  data  base 
format  by  using  the  SGML  tags  to  identify  pieces  of  information.  This  is  the  reason 
SGML  is  a  very  suitable  modelling  language.  SGML  also  had  a  very  flexible  structure 
which  can  be  checked  by  computer  programs  that  check  to  see  if  the  SGML  grammar  is 
correct..  It  allows  for  the  identification  of  data  elements  to  be  separated  from  the 
formatted  representations  of  those  elements. 
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Figure  12.  Weapon  System  Hierarchy. 


CDM  Elements 

pie  main  element  of  the  CDM  is  "techinfo."  This  tag  labels  the  beginning  of  the 
technical  information.  Within  the  techinfo  structure,  the  first  tag  is  the  system  tag.  A 
system  can  represent  the  vehicle,  an  aircraft  system,  a  subsystem,  or  a  subassembly.  At 
any  level  within  this  hierarchy,  elements  may  reference  associated  information.  These 
references  may  include  procedural  task  information,  descriptive  information,  parts 
information,  fault  information,  or  operational  information.  Figure  13  illustrates  the  CDM 
structure. 

Procedural  task  information  consists  of  maintenance  tasks  or  procedures.  A  task 
consists  of  a  set  of  input  conditions,  a  list  of  steps,  a  list  of  follow-on  tasks,  and  the 
estimated  time  and  action  for  the  task.  Input  conditions  may  include  required  conditions, 
personnel  required,  equipment  required,  and  consumables.  The  input  conditions  and 
steps  may  also  connect  to  warnings,  cautions,  notes,  and  user  annotations  which  are 
comments  entered  by  the  technician  as  he  is  using  the  data. 

Descriptive  information  defines  general  purpose,  non-procedural,  narrative 
information  such  as  that  contained  in  the  theory  of  operation,  schematics,  and  wiring 
diagrams. 

There  are  two  types  of  parts  information.  The  first  describes  an  item  by  its  reference 
designator  which  arranges  the  parts  by  their  place  in  the  system-subsystem  hierarchy. 
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This  is  the  maintainer’s  view  of  the  part  information.  This  information  is  related  to  the 
second  category  of  parts  which  describes  the  item  by  its  part  number.  This  is  the  supply 
system’s  view  of  the  part  information. 


Procedural.  Descriptive 
Parts.  Fault  Isolation, 
and  Operation 
Information 


Procedural,  Descriptive 
Parts,  Fault  Isolation, 
and  Operation 
Information _ 


Procedural,  Descriptive 
Parts,  Fault  Isolation, 
and  Operation 
Information 


Procedural.  Descriptive 
Parts,  Fault  Isolation, 
and  Operation 
Information _ 


Procedural,  Descriptive 
Part3,  Fault  isolation, 
and  Operation 
Information 


Part  Information 


Figure  13.  CDM  Element  Hierarchy. 

Three  types  of  fault  information  can  be  described  in  the  CDM: 
fault  reporting  decision  trees; 
fault  isolation  decision  trees;  and, 
dynamic  fault  isolation  model  data. 

The  fault  reporting  and  fault  isolation  decision  trees  are  static,  pre-defined  decision 
sequences.  Complete  decision  trees  are  defined  in  the  data.  A  dynamic  fault  model 
generates  the  decision  sequence  at  display  time  based  on  a  fault  model  of  the  equipment 
being  repaired.  For  a  dynamic  fault  isolation  model,  only  the  data  needed  to  represent 
the  fault  model  of  the  equipment  is  defined  in  the  data. 

All  of  the  diagnostic  structures  consist  of  diagnostic  tests,  test  outcomes,  fault  states, 
repairable  faults,  and  fault  rectification  actions.  The  fault  reporting  and  isolation  process 
begins  with  a  diagnostic  test  which  will  have  associated  outcomes.  These  outcomes 
connect  the  test  outcomes  with  new  fault  states.  Test  outcomes  are  described  as 
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preconditions  which  are  asserted  by  the  test  procedure  as  the  test  is  being  performed. 
The  test  outcome  element  relates  the  possible  test  outcomes  to  fault  states.  Once  a  fault 
is  identified,  the  rectification  procedure  associated  with  the  fault  is  performed. 

The  technical  information  in  the  CDM  consists  of  several  types  of  data.  These 
include  text,  graphics,  audio  sequences,  video  sequences,  and  external  software 
processes.  Elements  within  the  CDM  can  be  cross-referenced  to  other  elements  within 
the  CDM  or  to  external  information.  Prompts  define  one  type  of  user  interaction.  A 
prompt  may  be  either  a  fill-in-the-blank  or  menu  choice  for  the  user.  Prompts  assert 
properties  depending  on  the  user’s  response  to  the  prompt.  A  property’s  value  can  be 
asserted  er  tested  by  the  presentation  software.  An  assertion  is  made  whenever  a  task  or 
step  is  performed.  A  precondition  is  a  test  for  the  status  of  a  property.  It  is  also  possible 
to  define  a  prompt  or  task  to  acquire  a  value  for  a  property  if  the  value  does  not  already 
exist. 

The  CDM  allows  access  of  technical  information  in  u  hypertext-like  manner. 
Hypertext  is  a  system  which  allows  the  user  to  access  related  data  in  a  data  base  from  any 
specific  point  within  the  data  base.  It  also  allows  the  presentation  of  different  information 
depending  on  the  circumstances.  CDM  elements  may  have  “context”  which  determine 
the  applicability  of  a  particular  data  element  to  the  situation  at  hand.  Properties, 
preconditions,  and  assertions  may  also  define  the  conditions  at  any  given  point  in  time. 

CDM  Attributes 

SGML  attributes  define  the  relations  between  the  elements.  Two  common  attributes 
include  the  “id"  and  “refid”  attributes.  These  two  attributes  are  used  as  element 
identifiers.  These  identifiers  are  machine  generated  symbols  used  to  identify  the  data 
elements.  These  identifiers  are  not  human  readable  names  but  only  machine  readable 
pointers  or  references.  Most  elements  within  the  CDM  have  both  the  unique  identifier 
(id)  and  the  non-unique  reference  identifier  (refid).  The  reference  identifier  is  used  by 
the  elements  to  refer  or  point  to  other  elements.  For  example,  a  task  element  may  refer 
to  a  list  of  steps.  Since  the  reference  identifier  is  not  unique,  it  may  refer  to  several 
elements  within  the  data  base.  These  referenced  elements  will  have  a  different  context 
which  will  be  used  to  determine  which  unique  element  is  appropriate  for  a  particular 
situation. 

When  one  element  refers  to  another  element,  the  first  element  has  an  attribute  which 
is  named  identically  to  the  second  element.  The  attribute  value  is  a  list  of  reference 
identifiers  pointing  to  the  appropriate  elements.  For  example,  if  a  task  refers  to  a  set  of 
steps,  the  step  attribute  will  nave  a  list  of  reference  identifiers  which  point  to  the 
appropriate  groups  of  steps  as  an  attribute  value. 

Other  common  attributes  include  the  name,  type,  and  item  identifier  attributes.  The  ^ 
name  attribute  designates  the  name  of  the  element’s  content.  The  type  attribute 
designates  the  type  of  the  element.  The  item  identifier  (itemid)  identifies  the  equipment 
using  a  specific  identifier.  For  example,  a  system  might  have  a  name,  “GUN  SYSTEM”, 
a  type,  “M61A1”  and  an  item  identifier  which  may  be  the  system,  subsystem,  subject 
number  (SSSN)  of  a  system  or  tail  number  of  an  aircraft. 

IV.  CDM  VALIDATION  EFFORTS 

After  the  Content  Data  Model  had  been  developed,  it  was  necessary  to  prove  that  the 
model  could  accomplish  the  planned  objectives  and  produce  the  expected  benefits  in  a 
practical,  cost  effective  manner.  To  demonstrate  this,  sample  data  was  developed  using 
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CDM  requirements.  The  data  was  then  output  in  several  formats  to  demonstrate  the 
flexibility  of  the  model. 


Objective 

The  objectives  of  the  CDM  validation  efforts  were  to  demonstrate  that:  a)  the  CDM 
could  efficiently  produce  and  present  technical  information  for  a  weapon  system  in 
today’s  and  tomorrow’s  maintenance  environment,  and  b)  that  an  integrated  data  base 
could  produce  the  expected  benefits. 


Approach 

A  three  phased  approach  was  implemented  to  validate  the  CDM.  The  three  phases 
included  concept  exploration,  limited  demonstration  and  validation,  and  full-scale 
demonstration  and  validation.  This  approach  closely  resembles  the  Air  Force’s 
acquisition  approach  for  a  system.  In  order  to  validate  the  integrated  data  base  concepts, 
a  data  base  using  the.  CDM  structure  was  developed  and  data  loaded  into  and  extracted 
from  it  in  different  forms. 

Concept  exploration  began  with  the  examination  of  current  technical  manuals.  This 
examination  provided  information  about  the  types  of  data  required  and  the  structure  of 
the  data  within  the  technical  manuals.  It  also  provided  insight  into  ways  of  optimizing  the 
data  for  an  integrated  data  base.  A  portion  of  the  exploration  included  a  study  to 
determine  the  compatibility  of  CDM  data  with  ITDS.  A  compatibility  study  was  also 
performed  for  APS.  These  comparisons  provided  additional  information  concerning  the 
content  and  structure  of  technical  information.  The  information  from  these  studies  aided 
in  the  development  of  the  CDM. 

In  the  limited  demonstration  and  validation  phase,  the  CDM  structure  was  reviewed. 
This  structure  resembled  the  structures  found  within  the  technical  manuals.  A  small 
amount  of  data  contained  in  paper  manuals  was  entered  into  a  CDM  data  base  to 
determine  if  the  struct  »re  was  appropriate  for  the  intended  information.  Software 
routines  converted  ITDS  data  to  CDM  and  vice  versa.  Another  routine  converted  ITDS  to 
gencodes  used  by  the  ITDS  data  delivery  system.  Additional  conversion  routines  were 
developed  to  convert  APS  data  to  CDM  and  vice  versa. 

After  the  demonstration  and  validation  phase,  the  CDM  structure  was  modified  to 
more  accurately  model  the  data.  The  new  structure  modelled  the  information 
hierarchically,  based  on  the  structure  within  a  specific  weapon  system.  This  model  was 
used  for  the  full  scale  demonstration  and  validation  phase.  In  the  full-scale 
demonstration  and  validation  phase,  a  complete  set  of  information  was  entered  into  the 
CDM  for  a  specific  subsystem  of  a  major  weapon  system.  Data  was  entered  into  and 
extracted  from  the  CDM  in  a  number  of  ways  during  both  demonstration  and  validation 
phases,  validating  the  concept  of  an  integrated  data  base. 

Documentation  produced  during  the  effort  was  developed  to  provide  a  means  in 
which  to  procure  integrated  CDM  technical  information.  This  documentation  included  a 
data  exchange  standard,  a  data  item  description,  and  an  implementation  specification  for 
digital  technical  information. 


&MipatihUitaLStugfe& 

A  major  consideration  in  the  exploration  of  the  CDM  concept  was  the  requirement 
that  CDM  data  be  compatible  with  data  developed  and  stored  in  other  formats.  This 
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upward  compatibility  gives  the  Air  Force  the  ability  to  upgrade  technical  information  to 
the  CDM  format  without  the  need  to  re-develop  the  data.  To  assure  compatibility  with 
other  technical  data  base  systems  either  currently  in  use  or  in  development,  the 
compatibility  of  data  between  the  CDM  and  various  existing  systems  was  studied. 
Systems  which  were  examined  included: 

1.  Digital  data  intended  for  paper  presentation  developed  under  MIL-M-28001. 

2.  ITDS,  an  electronic  data  delivery  system  not  already  in  use. 

3.  APS,  an  electronic  authoring  and  data  delivery  system  developed  by  AFHRL. 
Compatibility  with  MIL-M-28001 

Data  developed  for  delivery  on  paper  was  included  to  determine  if  the  CDM  could 
represent  existing  technical  information.  The  ability  to  convert  existing  technical 
information  allows  the  Air  Force  to  convert  existing  digital  data  for  weapon  system 
manuals  into  the  CDM. 

MDL-M-28001  contains  two  DTDs  in  its  appendices.  One  DTD  defines  the  structure 
for  technical  manuals  developed  under  the  requirements  set  forth  in  MEL-M-38784.  The 
other  DTD  defines  a  structure  for  documents  not  covered  by  MIL-M-38784. 

Method.  The  SGML  tags  and  structures  in  the  MIL-M-38784  compliant  DTD 
contained  within  MIL-M-28001  were  examined  for  compatibility  with  the  CDM.  Rules 
for  the  conversion  of  the  data  were  defined  which  allowed  the  data  to  retain  its  content 
and  structure  while  deleting  any  format  information  which  was  connected  to  it. 

Results.  It  was  determined  that  data  tagged  under  the  MIL-M-38784  compliant  DTD 
could  be  loaded  into  a  data  base  developed  using  the  CDM  structure. 

CflropatMity  with  flPS 

The  ITDS  technical  data  system  was  examined  for  compatibility  with  the  CDM. 
ITDS  implements  SGML  in  a  different  manner  than  the  CDM. 

Method.  A  study  was  done  to  determine  the  feasibility  of  converting  data  between 
ITDS  and  the  CDM.  The  discovery  of  some  minor  incompatibilities  led  to 
recommendations  for  design  changes  to  both  systems  which  would  make  them 
compatible. 

Results.  After  the  implementation  of  the  changes,  it  was  concluded  that  although 
fundamental  differences  in  the  implementation  techniques  of  the  two  systems  remained, 
the  two  systems  were  compatible.  These  remaining  differences  would  not  prohibit  the 
exchange  of  information  between  the  two  systems. 

The  main  differences  which  now  exist  between  ITDS  and  CDM  involve  their 
implementation  methodologies.  FTDS  models  the  technical  data  sequentially  using  SGML 
commands  embedded  within  the  data.  ITDS  stores  format  information  within  the  text, 
causing  a  need  to  store  a  piece  of  data  multiple  times.  The  CDM  models  maintenance 
information  hierarchically  and  uses  SGML  markup  codes  to  identify  information  content 
and  structure.  The  CDM  does  not  retain  any  format  information  allowing  the  same  piece 
of  data  to  be  stored  once  and  used  many  times. 

Compatibility  with  APS 

CDM  was  also  tested  for  compatibility  with  the  APS  for  several  reasons.  First,  APS 
data  is  stored  in  a  relational  data  base  structure  with  the  data  distributed  in  many  files. 
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Also,  the  interrelationships  between  the  elements  of  the  data  base  closely  resemble  those 
within  the  CDM.  Finally,  because  it  was  developed  by  AFHRL,  it  was  readily  available. 
The  organization  of  the  APS  data  base  would  be  a  test  to  validate  the  assumption  that 
data  stored  in  different  formats  was  convertible  to  CDM  data. 

Method.  Since  APS  was  a  direct  predecessor  to  the  CDM,  a  complete  compatibility 
study  was  not  done.  However,  the  data  elements  were  examined  and  compared  to  those 
in  the  CDM.  The  interrelationships  between  the  elements  were  also  examined. 

Results.  It  was  concluded  that  data  developed  using  APS  could  be  loaded  into  a  data 
base  developed  according  to  the  CDM  structure. 

Results  of  Compatibility.  Studies 

MIL-M-28001,  rTDS,  and  APS  data  were  all  found  to  be  compatible  with  the  CDM. 
The  next  step  was  to  develop  a  CDM  data  base  and  populate  it  with  actual  technical 
information.  In  addition  to  the  development  of  the  data  base,  conversion  routines  would 
be  developed  to  demonstrate  that  data  could  be  interchanged  between  the  different 
systems. 

Limited  Pemonstratlon/Valtdation 

After  the  determination  was  made  that  the  CDM  was  compatible  with  several 
existing  standards  and  systems,  the  concept  had  to  be  demonstrated  and  validated.  A 
small  sample  of  data  was  used  to  demonstrate  that  the  various  data  structures  contained 
in  the  technical  information  could  be  modelled  in  the  CDM. 

Daia.S.cls£iifln 

In  order  to  validate  the  CDM  concept,  CDM  data  was  developed.  The  use  of  existing 
maintenance  information  allowed  the  current  technical  manual  requirements  to  be 
modelled  as  closely  as  possible.  The  data  used  in  the  demonstration  and  validation  phase 
was  initially  limited  to  organizational  level  maintenance  manuals  for  the  M61A1  and  M61 
automatic  gun  system  as  implemented  on  the  F-15  and  F-16  aircraft.  The  gun  system 
was  chosen  to  demonstrate  that  the  same  data  could  be  used  on  many  different  weapon 
systems.  It  was  thought  that  if  the  gun  system  was  not  altered  from  one  aircraft  to 
another,  the  CDM  for  the  F-15  gun  system  would  be  very  similar  to  the  CDM  developed 
for  the  F-16  gun  system. 

During  this  investigation,  it  was  discovered  that  the  CDM  data  bases  for  the  F-15 
and  the  F-16  were  not  me  same.  The  presentation  of  the  technical  information  within  the 
manuals  was  different  for  each  weapon  system  even  though  me  same  gun  was  being  used. 
In  some  cases,  me  information  sequence  was  also  different.  The  investigation  determined 
that  the  differences  were  subtle  and  would  not  alter  the  test. 

Five  job  guide  tasks  and  five  fault  isolation  procedures  were  chosen  for  the  F-15. 
Corresponding  tasks  and  procedures  were  chosen  for  the  F-16. 

Data  Mapping 

This  phase  included  me  development  of  DTDs  for  me  job  guide  and  fault  isolation 
manual. 

Job  Guide  DTD.  The  development  of  the  job  guide  DTD  used  the  MIL-M-38784 
compliant  DTD  contained  in  MIL-M-28001  as  a  baseline.  Additional  structures  were 
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developed  by  examining  and  mapping  the  data  required  for  job  guides  in  accordance  with 
MIL-M-83495.  Existing  job  guides  were  also  examined  to  determine  any  necessary 
additions  or  revisions  in  order  to  correctly  model  current  job  guides.  Several  differences 
were  discovered  between  the  F-15  and  F-16  job  guides;  however,  most  of  these 
differences  involved  the  format  of  the  manuals  which  was  not  included  in  the  DTD. 
Appendix  B  contains  the  job  guide  DTD. 

Fault  Isolation  Manual  DTD.  The  development  of  the  fault  isolation  manual  DTD 
used  the  MEL-M-38784  compliant  DTD  contained  in  MIL-M-28001  as  a  base  line.  The 
Fault  Isolation  Manual  DTD  was  developed  because  of  the  structural  differences  between 
the  two  manuals.  MIL-M-83495  was  used  to  develop  some  of  the  structures  while 
examination  of  existing  fault  isolation  manuals  provided  other  structural  information.  As 
was  the  case  with  the  job  guides,  some  format  differences  were  found  between  manuals 
from  the  two  weapon  systems.  These  format  differences  had  no  bearing  on  the  DTD. 
Appendix  C  contains  the  fault  isolation  manual  DTD. 

Data  EntE 

The  textual  data  contained  in  the  job  guides  and  fault  isolation  manuals  was  entered 
into  electronic  format  using  conversion  routines  and  direct  entry.  A  scanner,  which 
produced  raster  images,  was  used  to  enter  graphic  data.  A  CAD  program,  which 
produced  vector  images,  was  also  used.  Figure  14  illustrates  the  processes  used  in  the 
creation  and  entry  of  the  data. 

Conversion.  The  textual  data  for  the  F-16  job  guides  and  fault  isolation  manuals 
was  originally  provided  in  electronic  form  on  magnetic  tape.  The  data  was  loaded  onto  a 
Digital  Equipment  Corporation  VAX  computer.  The  data  was  then  downloaded  from  the 
VAX  to  an  IBM  PC  computer  using  communications  software.  Once  the  data  had  been 
downloaded,  random  characters  remained  within  the  file.  A  pre-processing  computer 
program  removed  these  characters  from  the  file. 

Direct  Entry.  Data  for  the  F-15  was  manually  entered  using  a  word  processing 
program  on  the  IBM  PC  since  the  data  was  not  readily  available  in  electronic  form.  Two 
different  strategies  were  used.  In  the  first,  the  text  was  entered  followed  by  the  insertion 
of  SGML  tags.  In  the  second,  the  text  was  tagged  as  it  was  entered. 

Tagging.  Tagging  of  the  F-15  and  the  F-16  data  was  initially  done  using  the 
Writerstation,  a  tagging  program  developed  by  Datalogics.  The  Writerstation  used  an 
ASCII  text  file  containing  the  DTD  for  the  document  to  be  tagged  and  the  text  file 
containing  the  untagged  data  as  input.  The  program  used  the  DTD  to  prompt  the  user  for 
the  appropriate  tag  and  attribute  information  which  was  then  inserted  into  the  text  to 
produce  an  SGML  document  instance.  Due  to  the  numerous  changes  in  the  DTDs  as  the 
data  was  being  developed  and  tagged,  the  Writerstation  was  abandoned  in  favor  of  an 
ASCII  text  editor.  Using  the  text  editor,  tags  and  attributes  were  inserted  in  the 
appropriate  places  within  the  text  file. 

Parsing.  Following  the  tagging  of  a  document  instance,  a  parser  verified 
conformance  to  the  appropriate  DTD  and  to  the  SGML  standard.  The  parser  program 
checked  for  correctness  of  the  markup  as  well  as  tag  sequence  and  completeness.  If 
errors  were  found,  they  were  corrected  and  the  file  was  reparsed  until  no  more  errors 
occurred. 

Data,  Loading 

The  lagged  document  instances  for  each  type  of  manual  was  converted  from  ASCII 
text  files  into  relational  data  base  structures  which  were  designed  based  upon  the  CDM 
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structure.  The  information  was  loaded  into  Canonical  Document  Representation 
(CANDOR)  relational  data  base  tables  (1  table  per  manual  type)  which  allowed  random 
access  to  the  data.  The  process  involved  reading  the  document  instance  for  each 
document  and  inserting  the  data  into  the  appropriate  location  within  a  CDM  data  base. 
This  process  produced  a  CDM  data  base  for  each  document  type.  The  manual 
combination  of  the  individual  CDM  data  bases  produced  a  single,  complete  CDM  data 
base.  Figure  15  illustrates  the  conversion  of  the  technical  manual  data. 
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Figure  IS,  Data  Loading  for  Limited  Demonstration/Va'idation. 

DaMLExtrastion 

The  data  extraction  process  involved  a  reverse  of  the  loading  process.  A  program, 
which  extracted  the  necessary  data  for  the  particular  manual,  read  the  data  stored  in  the 
CDM  data  base.  The  extracted  data  was  then  assembled  into  a  separate  data  base  before 
conversion  into  a  SGML-tagged  document  instance.  Figure  16  illustrates  the  processes 
used  for  the  extraction  of  data  from  the  CDM. 

In  order  to  perform  a  quality  check  on  the  extracted  information,  a  phototypesetter 
routine  was  used  to  produce  paper  output.  Since  the  original  data  being  loaded  into  the 
CDM  was  primarily  from  paper  manuals,  paper  output  allowed  for  easy  comparison  of 
the  original  data  and  the  extracted  data. 

In  order  to  typeset  the  manuals,  an  interim  output  specification  was  developed.  This 
output  specification  provides  rules  for  the  formatting  of  the  data  in  approximately  the 
same  way  as  the  original  manuals.  During  the  process  of  developing  the  output 
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algcrithms,  differences  in  format  were  found  between  the  manuals  for  the  different 
weapon  systems.  In  cases  where  differences  were  found,  generalizations  were  made  for 
the  output  specification. 
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Figure  16.  Data  Extraction  for  Limited  Demonitration/V alidation. 

Pata.,CQnvcrsifln 

After  tile  development  and  testing  of  the  data  loading  and  extraction  procedures, 
routines  were  developed  which  converted  data  which  was  developed  and  stored  in 
different  formats  into  the  CDM  format.  These  conversions  demonstrated  that  data 
developed  and  used  on  other  systems  was  transferable  to  and  from  the  CDM  without  the 
need  to  revise  the  original  data. 

Data  was  converted  between  ITDS  and  CDM.  To  do  this,  ITDS  job  guide-like  data 
was  converted  into  a  job  guide  document  instance.  Since  paper  job  guide  data  was 
transferable  to  the  CDM,  it  was  assumed  that  ITDS  data  converted  to  job  guide  DID 
format  as  a  preliminary  step,  could  be  loaded  into  the  CDM. 

ITDS  to  CDM.  The  ITDS  system  used  its  own  hardware  to  deliver  the  data,  both 
electronically  and  on  paper.  This  required  the  inclusion  of  formatting  commands.  Since 
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the  CDM  retains  only  the  content  and  structure  of  the  data,  the  formatting  commands 
were  automatically  removed  as  the  conversion  was  done.  Many  of  the  elements  within  the 
job  guide  DTD  also  required  the  use  of  SGML  end  tags  to  denote  the  end  of  a  segment  of 
data.  These  tags  were  not  required  in  the  ITDS  scheme.  A  two-phase  conversion  process 
accomplished  the  conversion  of  the  data  and  the  insertion  of  the  end  tags.  Figure  17 
illustrates  the  two  phases  used  in  the  conversion  from  ITDS  to  CDM. 


The  first  phase  involved  the  conversion  of  the  ITDS  data  to  the  appropriate  SGML 
tags  and  then  the  removal  of  formatting  information.  A  program  read  the  input  file 
containing  ITDS  data.  Once  a  tag  v  ^  found,  the  program  referenced  a  tag  dictionary 
which  contained  all  of  the  job  guide  tag  equivalents.  If  an  equivalent  tag  existed,  the 
program  removed  the  ITDS  tag  and  inserted  the  equivalent  job  guide  tag.  If  an  equivalent 
tag  was  not  available,  it  was  assumed  that  the  tag  was  a  format  tag  and  thus,  not  required 
in  the  CDM.  Following  the  tag  exchange,  the  job  guide  tag  and  actual  data  were  written 
to  a  temporary  output  file.  This  process  continued  until  the  end  of  the  input  file. 

The  second  phase  involved  the  insertion  of  the  end  tags  in  the  proper  places  within 
the  output  file.  A  hierarchy  of  the  tags  contained  in  the  job  guide  DTD  was  developed.  A 
subroutine  read  the  temporary  file.  Once  a  tag  was  encountered  the  program  recorded 
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the  location  of  the  tag  within  the  hierarchy.  If  a  tag  of  lesser  value  was  encountered,  the 
program  continued  to  search  for  the  next  tag.  If  a  tag  of  equal  value  was  encountered, 
the  program  inserted  an  end  tag  into  the  output  file  for  the  previous  tag  at  that  level, 
recorded  the  new  tag,  and  continued  to  search  for  the  next  tag.  If  a  tag  of  higher  value 
was  encountered,  the  program  inserted  end  tags  into  the  output  file  for  all  the  tags  up  to 
the  level  of  the  encountered  tag,  recorded  the  new  tag,  ana  continued  to  search  for  the 
next  tag.  This  process  continued  until  the  end  of  the  temporary  file.  At  that  point,  the 
program  closed  all  of  the  files  and  stopped. 

After  the  completion  of  the  conversion  process,  a  parser  checked  the  generated  job 
guide  document  instance  to  determine  adherence  to  the  job  guide  DTD  and  the  SGML 
standard. 

CDM  to  FTPS.  The  conversion  of  data  from  the  CDM  to  ITDS  required  the  insertion 
of  formatting  tags.  ITDS  requires  these  formatting  tags,  but  they  are  not  included  in  the 
CDM.  In  this  conversion,  job  guide  data  was  extracted  from  the  CDM  and  stored  as  job 
guide  document  instances.  A  program  read  the  input  file  containing  the  job  guide  data. 
Once  a  tag  was  found,  the  program  referenced  a  tag  dictionary  containing  all  of  the  ITDS 
tag  equivalents.  If  an  equivalent  tag  existed,  the  program  removed  the  job  guide  tag  and 
inserted  the  equivalent  ITDS  tag.  If  an  equivalent  tag  was  not  available,  it  was  assumed 
that  the  tag  was  not  required  in  ITDS,  so  no  equivalent  tag  was  required.  After  the  tag 
exchange,  the  ITDS  tag  and  actual  data  were  written  to  an  output  file.  This  process 
continued  until  the  end  of  the  input  file  was  reached.  At  that  point  the  program  closed  all 
of  the  files  and  stopped.  Figure  18  illustrates  the  CDM  to  ITDS  conversion  process. 


conversion  process. 


During  this  conversion,  formatting  commands  were  automatically  inserted  into  the 
file  as  the  tags  were  convened.  Since  the  CDM  does  not  store  format,  the  routine  had  to 
make  some  formatting  assumptions  which  would  typically  be  made  bv  the  ITDS  technical 
writer.  These  assumptions  were  implemented  by  using  the  “graphic4  tag  used  in  the  job 
guide  DTD  to  trigger  the  insertion  o f  format  tags.  Job  guides  are  printed  with  instructions 
on  the  left  page  and  the  accompanying  graphic  on  the  facing  page  on  the  right.  Whenever 
a  reference  to  a  new  graphic  occurred,  it  was  assumed  that  a  page  break  would  be  needed 
in  the  ITDS  paper  output,  or  a  different  graphic  would  need  to  be  displayed  in  the 
electronic  output  At  these  points  the  appropriate  format  commands  were  inserted  into 
the  output  file.  These  insertions  formatted  the  data  in  approximately  the  same  manner  as 
a  technical  writer  would  format  the  data  for  use  in  ITDS. 

ITDS  to  Gencode.  At  the  time  of  this  effort,  machines  running  under  the  ITDS 
tagging  structure  used  Document  Exchange  Standard  codes  or  gencodes  to  tag  the  data. 
Gencodes  are  a  more  cryptic  tagging  scheme  which  were  adopted  before  the  SGML 
standard  was  developed.  In  order  for  data  tagged  using  ITDS  SGML,  tags  to  be  used  on 
an  ITDS  machine,  it  had  to  be  translated  into  the  gencode  format.  A  program  read  an 
input  file  containing  ITDS  SGML  data.  Once  an  ITdS  SGML  tag  was  found,  the  program 
referenced  a  tag  dictionary  containing  all  of  the  gencode  tag  equivalents.  If  an  equivalent 
tag  existed,  the  program  removed  the  ITDS  SGML  and  inserted  the  equivalent  gencode 


and  inserted  the  equivalent  gencode 


tag.  Following  the  tag  exchange,  the  gencode  f.ag  and  actual  data  were  written  to  an 
output  File.  Tnis  ;  rocess  continued  until  the  end  of  the  input  File  at  which  time  the 
program  closed  all  of  the  Files  and  stopped.  Figure  19  illustrates  the  process  used  to 
convert  ITDS  data  to  gencode  tagged  data. 

An  operational  ITDS  machine  was  not  available  for  use  in  testing  the  data.  Instead, 
Northrop  ITDS  technical  writers  were  consulted  for  their  opinion  of  the  quality  of  the 
gencode-tagged  data.  It  was  the  general  consensus  that  the  data  conversion  was 
successful  and  the  data  would  be  compatible  with  ITDS. 


EXTRACTED 
FROM  COM 


Job 

Quids 

Data 

Bass 


CONVERTED 
TO  JOB  GUIDE 
SGML 


Taggsd 

Job  Quids 


DATA 

CONVERTED 
TO  ITDS 


Figure  18.  CDM  to  ITDS  Conversion. 


A  conversion  from  gencodes  to  ITDS  SGML  was  not  included  since  changes  to  the 
SGML  standard  had  not  been  finalized  by  the  National  Institute  of  Standards  and 
Technology  (NIST)  and  the  Aerospace  Industries  Association  (AIA). 
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To  demonstrate  that  data  developed  using  a  separate  authoring  system  and  stored  in 
a  different  data  base  layout  could  be  compatible  with  the  CDM,  a  conversion  of  APS  data 
to  CDM  data  was  accomplished  by  AFHRL  in-house  resources  and  RJO. 

APS  to  CDM.  Data  developed  using  APS  was  stored  in  a  relational  data  base  in 
binary  format.  In  order  to  load  this  data  into  the  CDM,  an  APS  DTD  was  r*  .eloped. 
Next,  a  program  converted  the  APS  binary  information  into  an  APS  document  instance. 
The  program  opened  a  configuration  file  which  contains  the  order  in  which  the  thirteen 
APS  binary  files  are  to  read.  This  file  acts  as  a  control  mechanism  for  the  program.  As 
the  program  read  each  input  file,  the  element  and  attribute  information  is  extracted  and 
converted  into  an  SGML  format.  The  SGML  information  is  then  written  to  the  output  file. 
This  continues  until  all  of  the  input  files  have  been  converted  at  which  time  the  program 
closes  all  of  the  files  and  stops.  Once  the  APS  SGML  file  was  completed,  the  data  could 
then  be  loaded  into  the  CDM  CANDOR  tables.  Figure  20  illustrates  the  conversion  of 
APS  data  to  the  CDM. 


Figure  20.  APS  to  CDM  Conversion. 

CDM  to  APS.  The  conversion  of  CDM  data  to  APS  binary  data  involved  three  steps. 
First,  the  required  data  was  extracted  from  the  CDM  CANDOR  table  and  written  to  an 
APS  SGML  text  file.  In  the  second  step,  a  program  read  the  APS  SGML  text  file  for 
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SGML  tags.  As  tags  were  encountered,  attribute  data  was  written  to  temporary  ASCII 
files  depending  on  the  tag  encountered.  After  the  extraction  of  all  of  the  attribute 
information,  the  program  read  and  converted  temporary  files  into  a  binary  data  base 
format.  Figure  21  presents  the  steps  taken  to  convert  CDM  data  back  to  APS. 
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Figure  21.  CDM  to  APS  Conversion. 

Results  of  Limited ‘Demonstration/Validation 

AFHRL,  RJO,  and  Datalogics  conducted  a  formal  demonstration/tutorial  in 
December,  1988.  In  this  demonstration,  Air  Force  and  contractor  personnel  were  briefed 
on  the  work  that  had  been  accomplished  to  that  point.  Demonstrations  also  provided 
evidence  that  data  could  be  loaded  into  and  extracted  from  the  CDM  in  many  different 
formats.  Conversions  from  APS  and  ITDS  also  showed  that  data  developed  and  stored 
using  different  systems  and  different  data  base  designs  could  be  compatible  with  the 
CDM.  Future  plans  were  also  discussed.  These  plans  included  the  further  testing  of  the 
CDM  and  the  development  of  documentation  to  accompany  the  CDM  specification. 
Figure  22  illustrates  the  entire  process  used  in  the  limited  demonstration  and  validation  of 
the  CDM. 
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Eigure  22.  Limited  Demonstration/Validation 


Full-Scale  Demonstration/Validation 


Following  the  limited  demonstration  and  validation,  the  CDM  was  redesigned  to 
accommodate  the  data  and  structures  found  in  intermediate  and  depot  level  manuals  (see 
Section  ID). 

Data. Selection 

To  further  validate  the  CDM  as  a  means  of  maintaining  technical  data  for  an  entire 
weapons  system,  it  was  necessary  to  load  all  of  the  data  for  a  specific  subsystem  within  a 
weapon  system  into  the  CDM.  This  further  validation  involved  the  inclusion  of  the 
intermediate  level  and  depot  level  maintenance  information  as  well  as  the  remainder  of 
the  organizational  level  information.  In  this  phase,  information  was  used  for  the  M61A1 
and  M61  automatic  gun  system  on  the  F-15  only.  It  did  not  seem  beneficial  to  also 
perform  further  validation  on  the  F-16  data  since  the  previous  variations  seemed  to  be 
primarily  format  oriented. 

Information  included  in  the  data  base  was  entered  from  the  following  types  of 
manuals: 

-  Organizational 

Job  Guide  (42  sections) 

Fault  Isolation  Manual  (26  fault  codes) 

General  System  Manual 
General  Vehicle  Manual 
Checklist 

-  Intermediate 

Intermediate  Maintenance  Instructions 
Illustrated  Parts  Breakdown 

-  Depot 


Overhaul  Instructions 
Data  Mapping 

A  revised  DTD  was  developed  for  the  CDM  which  described  the  structure  of  the 
technical  information  more  accurately  to  accommodate  differences  in  intermediate  and 
depot  level  data.  The  job  guide  and  fault  isolation  DTDs  were  also  modified  slightly. 
DTDs  were  developed  for  intermediate  maintenance  instructions  and  overhaul  instruction 
manuals  as  well. 

Job  Guide  DTD.  Differences  in  structure  and  format  were  found  in  the  additional 
job  guides  which  required  enhancements  to  the  original  job  guide  DTD.  The  DTD  was 
revised  to  model  these  differences. 

Fault  Isolation  Manual  DTD.  The  fault  isolation  manual  DTD  was  also  enhanced  as 
needed  for  the  additional  fault  isolation  manuals. 

Intermediate  Maintenance  Instructions  DTD.  The  DTD  for  intermediate  level 
maintenance  instructions  was  developed  using  the  MIL-M-38784  compliant  DTD 
contained  in  MIL-M-28001.  MIL-M-6675  was  used  to  develop  the  structures  while 
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examination  of  existing  intermediate  maintenance  manuals  provided  other  structural 
information.  Since  manuals  from  only  one  weapon  system  were  being  examined,  no 
format  differences  were  discovered  from  manual  to  manual.  Appendix  D  contains  the 
intermediate  maintenance  instructions  DTD. 


Overhaul  Instructions  DID-  The  development  of  the  overhaul  instruction  DTD  used 
|*|e  ^-M-38784  compliant  DTD  contained  in  MIL-M-28001  as  a  baseline. 
MIL-M-387S9  was  used  to  develop  structures  as  well  as  examine  existing  overhaul 
manuals.  Appendix  E  contains  the  overhaul  instruction  DTD. 


Data  Entry 


Data  used  for  the  specification  development  phase  of  the  effort  was  entered  using  a 
word  processor  on  an  EBM  PC.  Graphics  were  also  received  from  McDonnell  Douglas 
Aircraft  Company  in  the  Initial  Graphics  Exchange  Standard  (IGES)  format.  IGES  is  a 
standard  for  the  interchange  of  vector  graphics.  These  graphics  were  the  most  current 
graphics  contained  in  the  manuals  required  for  maintenance  on  the  gun  system.  In  some 
cased,  the  graphics  did  not  coincide  with  the  source  information  supplied  for  the 
development  of  the  CDM.  Figure  23  illustrates  the  process  used  to  enter  data. 

DilS&I  Entry.  The  textual  data  for  the  five  job  guide  and  five  fault  isolation  manuals 
developed  during  the  demonstration  and  validation  phase  was  enhanced.  The 
enhancements  included  the  revision  of  updated  tags  and  the  definition  of  previously 
undefined  attributes.  "Die  additional  job  guides  and  fault  isolation  manuals  as  well  as  the 
data  contained  in  the  intermediate  maintenance  instructions  and  overhaul  manuals  was 
entered  using  a  word  processing  program  on  an  IBM  PC. 


lagging-  The  data  entered  in  the  previous  step  was  tagged  in  accordance  with  the 
appropriate  DTD  using  an  ASCII  text  editor.  Tags  for  the  inclusion  of  the  IGES  graphics 
were  also  added  to  the  tagged  document  instances.  5  F 


Earsing-  As  was  done  in  die  demonstration  and  validation 
each  file  to  verify  conformance  to  the  DTD  and  to  SGML. 


phase,  a  parser  checked 


Data  Loading 


.  The  reyised  CDM  structure  required  that  the  loaders  developed  in  the  Demonstration 
and  Validation  phase  be  revised.  Also,  the  development  of  an  automatic  combining 

program  facilitated  the  development  of  small  CDM  files  which  could  be  merged  into  one 
large  CDM  data  file. 
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Direct  Loading.  Data  found  in  manuals  for  which  DTDs  were  not  developed  (i.e., 
Checklist,  General  System,  General  Vehicle,  Dlustrated  Parts  Breakdown)  was  tagged 
directly  into  the  CDM  structure  (see  Figure  24).  The  volume  of  data  specific  to  the  gun 
system  did  not  warrant  the  development  of  a  separated  DTD  for  each  manual  and  it  was 
determined  that  data  could  be  tagged  directly  into  the  CDM  structure.  This  was  done 
using  an  ASCII  text  editor.  The  data  was  successfully  entered  into  the  structure  but  the 
robustness  of  the  attributes  (i.e.,  cross  references,  etc.)  was  not  equal  to  the  data  which 
had  been  loaded  from  the  other  DTDs.  Tags  for  the  inclusion  of  the  IGES  graphics  were 
also  included  in  the  manually  developed  CDM  text  file. 
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Figure  24.  Direct  Loading  Into  the  CDM. 

Loading.  The  files  containing  the  job  guide,  fault  isolation,  intermediate 
maintenance,  and  overhaul  data  were  loaded  into  a  program  developed  using  the  General 
Expression  Pattern  Recognition  (GEPR)  language.  This  program  converted  the  text  files 
into  a  CDM  text  file.  The  information  contained  in  each  type  of  manual  was  loaded  into 
a  separate  CDM  text  file.  The  CDM  text  files,  including  the  manually  developed  file, 
were  then  converted  into  CANDOR  data  base  tables  for  processing  as  had  been  done  in 
the  demonstration  and  validation  phase.  Figure  25  shows  the  processes  used  for  loading 
data  into  the  CDM  structure. 
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Figure  25.  Loading  of  Data  Into  CDM  Data  Bases. 

Combining.  In  order  to  get  a  complete  CDM  containing  the  information  from  all  of 
the  manuals,  the  individual  CDM  CANDOR  tables  for  each  manual  were  combined  (see 
Figure  26).  This  was  done  by  a  program  developed  using  GEPR  which  designated  one  of 
the  CANDOR  tables  as  the  “master.”  The  program  was  run  on  this  master  table  which 
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eliminated  any  redundancy  within  it.  The  same  program  was  then  run  on  the  other 
CANDOR  tables  to  be  combined  with  the  “master"  table  to  create  a  complete  CDM 
CANDOR  instance: 


Figure  26.  Combining  of  CUM  Data  Bases  Into  Single  CDM. 
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Data  Extraction 

•  The  data  extraction  process  used  in  the  full  scale  development  and  validation  phase 
was  similar  to  that  used  in  the  limited  demonstration  and  validation  phase.  Based  on  the 
type  of  output  desired,  a  GEPR  program  extracted  the  required  information  from  the 
CANDOR  tables  using  the  DTD  as  a  guide.  The  output  consisted  of  an  SGML-tagged 
text  file  which  corresponded  with  the  appropriate  DID.  Figure  27  illustrates  the  data 
extraction  process. 


Figure  27.  Data  Extraction  For  Full  Scale  Demonstration/Validation. 


In  order  to  perform  quality  checks  on  the  extracted  information,  a  phototypesetter 
was  again  used. 


AFHRL,  RJO,  and  Datalogics  conducted  a  second  formal  demonstration/tutorial  in 
August  1989.  In  this  demonstration.  Air  Force  and  contractor  personnel  were  updated  on 
the  work  accomplished  to  that  point.  A  great  deal  of  emphasis  was  placed  on  the 
development  of  the  implementation  specification.  Plans  were  made  for  the  review  of  the 
specification  by  government  and  by  industry.  In  addition,  a  detailed  tutorial  on  the  CDM 
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was  presented  in  order  to  assist  those  in  attendance  in  the  development  of  CDM  data 
bases.  Figure  28  shows  the  processes  used  during  the  full  scale  development  and 
validation  of  die  CDM. 

Summara  .of  Results 

The  CDM  validation  efforts  showed  that  a  data  base  for  technical  information  could 
be  developed.  They  also  showed  that  the  data  base  could  be  loaded  in  a  number  of  ways 
and  data  could  also  be  extracted  in  a  number  of  ways.  Data  developed  and  stored  using 
other  systems  could  also  be  loaded  into  die  CDM  aas  well  as.  from  the  CDM. 

V.  DOCUMENTATION  DEVELOPMENT 

During  this  effort,  several  interim  documents  were  produced  which  documented  the 
progress  or  the  research.  These  are  listed  in  the  references  section.  Two  of  the  most 
important  documents  produced  during  this  effort  include  the  CDM  Exchange  Standard 
and  the  CDM  Implementation  Specification. 

CDM  JEx£lia.nss.Staadard 

Objective 

A  data  exchange  standard  was  developed  which  defined  the  structure  of  the  CDM 
data  base  as  it  will  be  exchanged  under  MIL-STD-1840.  This  standard  was  based  on  the 
CDM  DTD.  It  dictates  the  interchange  of  CDM  data  similar  to  the  way  in  v  hi  ;■> 
MIL-M-28001  dictates  the  format  in  which  the  current  paper  manuals  are  interchanged 

Scope 

At  this  time,  the  CDM  Exchange  Standard  addresses  the  interchange  of  maintenance 
and  operational  information.  Training,  manufacturing  and  logistics  information  are  not 
included  in  the  CDM  at  this  time  but  are  expected  to.be  added  in  the  future. 

Canicula 

The  exchange  standard  contains  the  CDM  DTD  which  will  be  used  for  the 
interchange  of  technical  information  under  MIL-STD-1840.  An  appendix  is  also 
included  which  provides  descriptions  of  all  the  data  element  tags  and  attributes.  This  was 
included  to  aid  the  user  who  is  unfamiliar  with  SGML  and  the  CDM. 

Specification  for  Digital  Technical  Information 

A  draft  specification  for  digital  technical  information  was  developed  which  outlined 
the  creation,  distribution,  processing,  and  use  of  digital  technical  information  designed  to 
support  the  traditional  functions  of  operation  and  maintenance. 

Objective 

The  specification  establishes  the  requirements  for  the  creation,  delivery.  and 
presentation  of  integrated  technical  information.  It  includes  requirements  for: 

1.  general  information  content,  authoring  style,  display  presentation,  and  user 
interaction. 
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2.  revisable,  format-free  technical  information.  - 

3.  view  packages  of  technical  information. 

4.  functional  presentation  system  hardware  and  software  requirements. 

5.  quality  assurance. 

6.  interchange. 

Scope 

The  specification  outlines  how  to  create,  distribute,  process,  and  use  integrated 
technical  information  to  support  the  traditional  functions  of  operation  and  maintenance. 

Contents 

The  specification  is  divided  into  six  sections  which  establish  the  requirements  an 
acquisition  activity  shall  consider  when  procuring  integrated  technical  information.  These 
requirements  cover  the  entire  life-cycle  of  the  information  from  creation,  *o  presentation, 
to  delivery  and,  finally,  validation. 

General  Information  Content.  Authoring  Style.  Display  Presentation,  and  User 
Interaction  Requirements.  Since  digital  technical  information  can  be  prepared  in  a 
number  of  ways  and  can  also  be  used  in  many  different  ways,  minimum  standards  for  the 
authoring,  display,  and  use  of  technical  information  are  specified.  These  standards 
include  the  informational  content,  authoring  style  guidance,  presentation,  and  user 
interface  requirements  for  digital  technical  information. 

Revisable  Technical  Information.  To  facilitate  the  maintenance  and  operation  of 
equipment,*  technical  information  may  be  presented  on  a  variety  of  media,  formatted  to 
comply  with  a  variety  of  specifications.  Even  though  the  information  may  be  used  in  so 
many  ways,  the  underlying  data  elements  required  to  support  maintenance  and  operation 
of  a  particular  piece  of  equipment  is  basically  the  same  for  all  equipment. 

View  Packages  of  Digital  Technical  Information.  A  view  package  is  a  subset  of  the 
digital  technical  information  that  supports  a  specific  objective.  The  information  is 
collected  and  formatted  based  on.  the  requirements  of  a  specific  function.  The  actual 
information  and  the  formatting  rules  make  up  the  view  package.  It  should  also  provide 
basic  guidelines  for  use  in  developing  specific  application  requirements. 

Ecgscmation-Sysigm  Rsauircmsms-  a  presentation  system  will  be  used  to  display 
view  packages  of  technical  information  to  the  users  of  the  information.  Types  of 
presentation  systems  will  vary  greatly.  Possible  presentation  systems  include: 
phototypesetters,  screen  frame  paging  systems,  interactive  color  workstations,  and 
hand-held  miniature  computers.  No  matter  what  type  of  presentation  system  is  utilized, 
they  all  have  a  common  purpose:  to  present  the  technical  information  contained  in  a  view 
package,  using  the  presentation  rules  associated  with  that  view  package,  so  that  the  final 
user  of  the  information  can  retrieve  accurate,  understandable  technical  information. 


Quality  Assurance  Requirements.  Quality  assurance  is  performed  on  the  technical 
information  in  two  ways.  First,  the  revisable  technical  information  data  base  may  be 
checked  for  several  items  including:  readability;  accuracy  of  attributes;  appropriateness  of 
cross-references;  naming  schemes;  flow  of  the  information;  appropriateness  and 
correctness  of  warnings,  notes,  and  cautions;  and  appropriateness  of  context  attributes. 
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Second,  the  output  of  the  technical  information  will  be  checked  for  the  content  of  the 
data,  the  arrangement  of  the  information  on  the  display  medium,  and  understandability  of 
die  presented  information. 

Interchange  Requirements.  Digitally  represented  technical  information  can  be 
interchanged  efficiently  between  dissimilar  computer  systems  using  MIL-STD-1840 
which  provides  a  framework  for  the  interchange  of  digital  technical  information  as  well  as 
addressing  media  types  and  packaging  of  the  technical  information.  Additions  will  need 
to  be  made  to  MfiL-STD-1840  to  govern  the  exchange  of  the  revisable  technical 
information,  view  packages,  and  presentation  system  software. 

VI.  SUMMARY/RECOMMENDATIONS 

These  Research  and  Development  (R&D)  efforts  have  shown  the  CDM  will  work. 
With  today’s  technologies,  a  single  data  base  can  be  developed  that  supports  O-Level, 
I-Level  and  D-Level  maintenance.  This  single  data  base  can  store  all  of  the  required 
content  *nd  structure  with  minimal  or  no  data  redundancy.  The  format  of  the 
maintenance  information  can  be  stored  outside  of  the  data  base  and  will  be  different  for 
each  output  device.  A  single  definition  of  format  can  be  established  for  each  output 
device  and  can  be  used  for  any  system's  maintenance  data  base. 

The  potential  savings  associated  with  this  concept  are  staggering.  With  this  type  of 
technology,  the  maintenance  data  base  will  not  have  to  be  changed  when  different  output 
devices  are  developed.  With  this  model,  the  USAF  could  revolutionize  technical 
information  far  beyond  current  programs  in  development. 

However,  there  are  still  significant  amounts  of  R&D  which  should  to  be  performed. 
The  benefits  of  the  CDM  have  to  be  verified.  This  verification  would  include  evaluating 
the  system  when  it  is  being  used  in  the  field  as  well  as  doing  Life  Cycle  Cost  estimates  to 
.  show  the  expected  savings. 

Finally,  the  CDM  must  be  continually  studied  and-  reviewed.  Such  review  would 
allow  the  CDM  to  adapt  to  a  rapidly  changing  environment.  A  two-phased  approach  for 
review  may  be  used.  The  first  phase  would  focus  on  continued  population  of  the  CDM 
with  even  more  data  to  further  assure  the  ability  to  implement  the  design.  The  second 
phase  would  involve  periodic  reviews  by  the  community.  Without  these  continual  reviews 
by  the  DoD  and  major  contractors,  the  CDM  will  not  be  proposed  or  implemented 
correctly. 

This  paper  has  described  the  evolution  of  the  CDM.  Detailed  descriptions  and 
explanations  are  given  to  assist  the  reader  in  understanding  the  concepts  involved  in  the 
CDM.  This  paper  has  also  described  efforts  to  demonstrate  and  validate  the  CDM 
concept  and  develop  specifications  for  the  exchange  of  the  technical  information. 
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GLOSSARY 


The  following  are  acronyms  and  abbreviations  used  throughout  this  report: 

AFHRL  Air  Force  Human  Resources  Laboratory 

AFLC  Air  Force  Logistics  Command 

AFSC  Air  Force  Systems  Command 

AIA  Aerospace  Industries  Association 

APS  Authoring  and  Presentation  System 

ASCT  American  Standard  Code  for  Information  Interchange 

ATOS  Automated  Technical  Order  System 

CAD  Computer  Aided  Design 

CALS  Computer-Aided  Acquisition  and  Logistics  Support 

CANDOR  Canonical  Document  Representation 
CDM  Content  Data  Model 

CMAS  Computer-Based  Maintenance  Aiding  System 

DoD  Department  of  Defense 

DTD  Document  Type  Definition 

DXF  Drawing  Interchange  File 

GEPR  General  Expression  Pattern  Recognition 

IGES  Initial  Graphics  Exchange  Standard 

IMIS  Integrated  Maintenance  Information  System 

IPB  Dlustrated  Parts  Breakdown 

ISO  International  Standards  Organization 

ITDS  Improved  Technical  Data  System 

NIST  National  Institute  of  Standards  and  Technology  (formerly  National 
Bureau  of  Standards) 

NTIPS  Naval  Technical  Information  Publishing  System 

SGML  Standard  Generalized  Markup  Language 

SSSN  System,  Subsystem,  Subject  Number 
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CONTENT  DATA  MODEL 
DOCUMENT  TYPE  DEFINITION 
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< ! DOCTYPE  techinfo [ 

<  ! 

A**************************************************************** 

Content  Oata  Modal  (CDM) 

Version  5.1  8/23/89  DRAFT 

This  document  is  an  SGML  Document  Type  Definition  (DTD)  which 
describes  the  logical  structure  for  a  database  of  technical 
information.  This  version  is  a  working  draft  which  is  still  under 
development  by  the  Air  Force  Human  Resources  Laboratory  (AFHRL/LRC) 
at  Wright  Patterson ,  AFB. 

Changes  from  Version  5.01  are  indicated  in  bold  face  type 
*******************************************  *****************  **__> 


Draft  Content  Data  Modal _ Virilon.  S  tX. _ _  ■  -  $/22i&3i 

<1-  ************************************************************* 


Entity  Declarations 

These  antity  daclarations  dafina  abbraviationa  for  a  sat  of 
frequently  usad  attributas:  "id",  "rafid". 

The  "%ids"  entity  declaration  defines  an  abbreviation  for  two 
element  identifiers  ("id"  and  "refid") .  These  identifiers  are 
machine  generated  symbols  used  to  identify  data  elements  in  the 
database .  These  identifiers  ar*  not  intended  to  be  human  readable 
names,  but  only  machine  readable  pointers  or  references.  Most 
elements  in  the  CDM  have  both  a  unique  identifier  ("id")  and  a 
non-unique  reference  identifier  ("refid").  The  reference 
identifier  ("refid")  is  usad  by  elements  to  refer  or  "point"  to 
other  elements.  For  example,  a  "task"  element  may  refer  to  a  list 
of  "step"  elements,  or  a  "system"  element  may  refer  to  a  list  of 
"subassembly"  elements.  since  the  reference  id  ("refid")  is  not 
unique,  it  may  refer  to  several  elements  in  the  database.  These 
referenced  elements  will  have  different  "context"  (such  as  version 
number  or  security  level)  which  will  be  used  to  determine  which 
unique  element  is  appropriate  for  a  particular  situation.  Sinca 
SGML  requires  that  all  "ID"  attributes  be  unique,  an  "ID"  attribute 
cannot  be  used  as  the  reference  id  ("refid") .  Instead,  "refid"  is 
defined  as  a  NMTOKEN. 

The  two  entities  "%refid"  and  "%refids"  are  defined  only  to  improve 
readability.  They  let  the  reader  know  that  an  attribute's  value 
is  meant  to  be  a  reference  identifier  (i.e.,  a  NMTOKEN  specifying 
some  element's  "refid").  These  two  entities,  "%refid"  and 
"%refids",  are  used  throughout  the  CDM  whenever  a  reference  is 
intended.  This  DTD  also  follows  the  convention  that  the  attribute 
name  of  any  "trefid"  attribute  is  the  same  as  the  element  name  to 
which  it  is  referring.  For  example,  the  "system"  element  has  an 
attribute  named  "task"  which  is  a  "%refids"  list  intended  to 
contain  only  valid  "refids"  to  "task"  elements.  There  is  on 
notable  exception  to  this  rule.  In  some  cases  an  "elmntref" 
attribute  is  defined  which  is  intended  to  be  a  reference  to  any 
element  type. 


*************************** ****************************4 »******-> 


< ! ENTITY 

%  ids 
refid 

"id  ID  '#  REQUIRED 

NMTOKEN  # REQUIRED" > 

<! ENTITY 

% 

re  f  id 

"NMTOKEN" > 

< I  ENTITY 

% 

ref ids 

"NMTOXENS"> 
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Draft  content  Bata  Modal _ version  s .  1  _ 9/23/89 

* 

<1— ************************************************************** 


Notation  Declaration* 

Tha  following  notations  define  external  references  to  "public" 
graphics  standards  used  in  the  CDM.  The  specified  abbreviations 
(cgmbin,  cgmclear,  cgmchar,  fax,  iges,  dxf,  gks)  are  used  by  the 
element  "graphprm"  to  specify  the  type  of  graphic  representation 
used  to  encode  a  particular  graphic  primitive. 

***************************************************************** 

**************************************__> 

< ! NOTATION  cgmbin  PUBLIC  "ISO  8632/2//NOTATION  Binary 
encoding//EN" > 

< ! NOTATION  cgmchar  PUBLIC  "ISO  8632/2//NOTATION  Character 
encoding//EN" > 

< ! NOTATION  cgmclear  PUBLIC  "ISO  8632/2//NOTATION  Clear  text 
encoding//EN"> 

<! NOTATION  fax  PUBLIC  " -//US A-DOD//NOTATION  CCITT  Group  4 
Facsimile//EN"> 

< ! NOTATION  iges  PUBLIC  " -//USA-DOD//NOTATION  Initial  Graphics 
Exchange  Specification//EN"> 

<  l  NOTATION  dxf  PUBLIC  " -//USA-DOD//NOTATION  DXF  Encoding//EN" 


<1 NOTATION  gks  PUBLIC  " -//USA- DOD// NOTATION  Graphics  Kernel 
System// EN"  > 


BSftlfc  Conttnt  Data,  Moflil 


Vriion  5.1 


M2 2131 


<1  — 


COM  Content 

"Techinfo"  is  ths  top  element  of  ths  COM  .  Its  content  model  is 
a  long  list  of  elements  (vehicle*,  system*,  ...  )  which  comprise 
the  raw  data  "records”  or  "tables"  for  the  COM  data  base.  The 
first  "system"  element  in  the  data  base  is  the  root  or  top  level 
item  in  the  hierarchy. 

**************************************************************--> 


<1 ELEMENT  techinfo  -  -  (  system*,  operinfo*,  descinfo*, 

task*,  input*,  step*, 

reqcond*,  person*,  equip*,  consum*,  verb*, 
warning*,  caution*,  note*,  annot*, 
partinfo*,  partbase*,  faultinf*  , 
test*,  outcome*,  fltstate*,  fault*,  rect*, 
text*,  title*,  dictitem*,  xref*,  table*,  list*, 
graphic*,  tgraphic*,  grphprim*, 
video*,  audio*,  process*, 
prompt*,  fillin*,  menu*,  choice*, 
assertion*,  precond*,  property*,  value*  )> 
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Draft  Content  Data*  Modal 


YtCllfln-5,1 


SU21/L&1 


<1— ************************************************************* 
* 

Vehicle  -  System  -  Subsystem  Hiararchy 

Tha  CDM  specifies  a  hierarchically  organized  data  base  of  technical 
information  for  a  weapon  system.  The  main  hierarchy  of  the  data 
base  parallels  the  equipment  hiararchy  of  the  weapon  system.  This 
is  no  mally  represented  as  a  vehicle  -  system  -  subsystem  - 
subassembly  hierarchy  in  AF  Technical  Orders.  That  hierarchy  is 
represented  in  the  CDM  by  the  "system"  element  specified  below. 
Here  "system"  is  used  in  its  most  generic  sense,  meaning  any 
component  or  item  in  the  equipment  hierarchy.  A  "system"  could 
represent  the  vehicle,  an  aircraft  system,  subsystem,  or 
subassembly. 

At  any  level  in  this  hierarchy  (vehicle,  system,  or  subassembly)  , 
elements  may  reference  associated  information.  They  may  reference 
procedural  task  information  (  "task"),  descriptive  information 
("desc"),  parts  information  ("partinfo") ,  fault  information 
("faultinf") ,  or  operational  information  ("operinfo") .  This 
information  should  be  attached  to  the  level  where  it  is  most 
appropriate.  For  example,  vehicle  towing  procedures  should  be 
referenced  at  the  "vehicle"  level.  The  removal  task  for  a  circuit 
card  in  the  radar  should  be  referenced  at  the  radar  "system"  level. 


The  "system"  element,  like  most  elements  in  the  CDM,  have  a  set  of 
attributes  ("name",  "type",  "itemid",  and  "xrefs")  which  describe 
the  nature  of  the  element's  content.  These  include  attributes 
defining  the  element's  "name"  and  "type".  There  is  also  an 
"itemid"  attribute  used  to  indicate  which  piece  of  equipment  (or 
"item")  is  related  to  the  information  element.  The  "itemid"  could 
be  a  reference  designator,  a  SSSN  number,  a  part  number,  etc., 
depending  on  the  item  of  interest.  There  is  also  an  attribute 
"xref"  which  defines  relational  links  between  the  element  and  other 
elements  in  the  database.  An  "xref"  specifies  the  reference 
identifier  for  a  related  element  and  the  type  of  relation  being 
specified. 


**#********************************&***************************—— 

> 


<! ELEMENT  system 
< 1 ATTLIST  system 


-  o  (  context*  )  > 

lids; 

name 

CDATA 

* IMPLIED 

type 

CDATA 

# IMPLIED 

itemid 

CDATA 

# IMPLIED 

xref 

IDREFS 

# IMPLIED 

system 

%ref ids; 

# IMPLIED 

operinfo 

%refids; 

# IMPLIED 

descinfo 

%ref ids; 

# IMPLIED 

task 

% re fids; 

# IMPLIED 

partinfo 

Ire fids ; 

# IMPLIED 
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faultinf  %rafida;  #IMFLI£D> 


< i —  *********************************************** 

Oparational  Information 


**************************************************************** 

-> 

<! ELEMENT  oparinfo  -  o  {  ^rtiat*)  > 

< ! ATTLIST  oparinfo  %idar 

naaa  CDATA  #IMPLIBD 

typa  CDATA  # IMPLIED 

itaaid  CDATA  # IMPLIED 

xraf  IDREP8  # IMPLIED 

daseinfc  %rafids;  # IMPLIED 

task  %rafida;  # IMPLIED  > 
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<1  _..w***********<.  ************************************************ 


Descriptive  Information 

The  element  "descinfo"  is  used  to  define  ganaral  purpose, 
non-procedural,  narrative  information  such  as  theory  of  operation, 
schematics,  wiring  diagrams,  etc.  "Descinfo"  is  a  very  flexible, 
general  purpose  information  node.  It  can  be  used  to  describe  any 
arbitrary,  hierarchical  hypertext-lifce  node  containing 
sub-paragraphs  ("descinfo") ,  data  ("title",  "text",  "table", 
"graphic",  "annot",  "audio",  "video",  "process"),  user  interaction 
instructions  ("prompt"),  and  assertion  properties  ("assertion") 
which  are  asserted  whenever  the  "descinfo"  is  read. 

********************************************************** **__> 

<! ELEMENT  descinfo  -  o  (  context*  )> 

<  2 ATTLIST  descinfo  %ids; 


name 

CDATA 

# IMPLIED 

type 

CDATA 

# IMPLIED 

itemid 

CDATA 

# IMPLIED 

xref 

IDREFS 

# IMPLIED 

assertion 

IDREFS 

♦ IMPLIED 

descinfo 

%refids 

# IMPLIED 

title 

%refid? 

# IMPLIED 

text 

%refid; 

# IMPLIED 

table 

%refids. 

♦IMPLIED 

graphic 

%refids 

♦IMPLIED 

idio 

%ref ids 

♦IMPLIED 

video 

%ref ids 

♦IMPLIED 

process 

%refids. 

♦IMPLIED 

annot 

%refidsj 

♦IMPLIED 

prompt 

%refidsj 

♦IMPLIED> 
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< !  — 


Task  Information 

The  elements  "task,"  "input,"  and  "stap"  dafina  a  maintenance  task 
or  procadura.  A  "task"  consists  of  a  sat  of  input  conditions 
("input"),  a  list  of  staps  ("stap"),  a  list  of  follow-on  tasks 
("followon"),  and  the  attributas  astimatad  tima  ("asttime")  and 
action  dascribing  "varb."  Tha  alamants  "raqcond"  (raquirad 
conditions),  "parson"  (parsonnal  raquirad),  "equip"  (equipment 
required),  "consum"  (consumables),  and  "verb"  describe  the  input 
conditions  referred  to  by  "input"  and  "stap."  The  additional 
alamants  "warning,"  "caution,"  "note,"  and  "annot"  (user 
annotations)  are  referenced  by  "input"  and  "stap." 

**************************************************************.-.> 


<! ELEMENT  task  -  o  (  context*  )> 

< ! ATTLIST  task  %ids? 

name  CDATA  # IMPLIED 

type  CDATA  # IMPLIED 

itemid  CDATA  # IMPLIED 

xraf  IDREFS  # IMPLIED 

asttime  NUTOKENS  #IMPLIED 

verb  %refids;  # IMPLIED 

input  trefid;  * IMPLIED 

stap  %rafids;  # REQUIRED 

followon  %refids;  #IMPLIED> 


<1 ELEMENT  input  -  o  (  context*  )> 

<! ATTLIST  input  %ids; 

name  CDATA  * IMPLIED 

type  CDATA  # IMPLIED 

itemid  CDATA  # IMPLIED 

xraf  IDREFS  # IMPLIED 

raqcond  %refids;  # IMPLIED 

parson  %refids;  # IMPLIED 

equip  %refids;  # IMPLIED 

consum  %refids;  # IMPLIED 

warning  %refids;  # IMPLIED 

caution  %refids;  # IMPLIED 

note  %refids;  #IMPLIED> 


<1  ELEMENT  step  -  o  (  context*  )> 

<! ATTLIST  stap  %ids; 

name  CDATA  # IMPLIED 

type  CDATA  # IMPLIED 

itemid  CDATA  # IMPLIED 

xref  IDREFS  # IMPLIED 

asttime  NUTOKENb  # IMPLIED 
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<! ELEMENT  reqcond 
<1ATTLIST  reqcond 


<1 ELEMENT  person 
< l ATTLIST  person 
nans 
type 
itemid 
xref 


<1 ELEMENT  equip 
<1 ATTLIST  equip 
name 
type 
itemid 
xref 

alteqids 


<1 ELEMENT  consum 
<1 ATTLIST  consum 
name 
type 
itemid 
xref 
milspec 
mfgcode 


assertion 

IDREFS 

step 

%refids? 

text 

%refid? 

table 

% ref ids; 

graphic 

%ref ids ; 

audio 

%refids; 

video 

Irefids; 

process 

%refids; 

annot 

%refids; 

prompt 

%refids; 

warning 

%refids; 

caution 

% re fids; 

note 

% re fids; 

verb 

% ref ids; 

reqcond 

%refids; 

person 

%refids; 

equip 

%refids; 

consum 

% ref ids; 

-  o  (  context*  ) > 
%ids; 

name 

CDATA 

type 

CDATA 

itemid 

CDATA 

xref 

IDREFS 

precond 

IDREFS 

elmntref 

%ref ids ; 

-  o  (  context*  )> 
%ids; 

CDATA 

♦IMPLIED 

CDATA 

♦IMPLIED 

CDATA 

♦IMPLIED 

IDREFS 

♦IMPLIED> 

-  Q  (  context*  )> 
%ids; 

CDATA 

♦IMPLIED 

CDATA 

♦IMPLIED 

CDATA 

♦IMPLIED 

IDREFS 

♦IMPLIED 

CDATA 

♦IMPLIED> 

-  o  ( 
%ids; 

context*  )> 

CDATA 

♦IMPLIED 

CDATA 

♦IMPLIED 

CDATA 

♦IMPLIED 

IDREFS 

♦IMPLIED 

CDATA 

♦REQUIRED 

CDATA 

♦REQUIRED 

* IMPLIED 
* IMPLIED 
♦REQUIRED 
# IMPLIED 
* IMPLIED 
* IMPLIED 
# IMPLIED 
* IMPLIED 
* IMPLIED 
# IMPLIED 
* IMPLIED 
# IMPLIED 
# IMPLIED 
# IMPLIED 
# IMPLIED 
# IMPLIED 
# IMPLIED 
#IMPLIED> 


♦IMPLIED 

♦IMPLIED 

♦IMPLIED 

♦IMPLIED 

♦IMPLIED 

♦IMPLIED> 
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govetd 

CDATA 

IRSQUIRED 

qty 

NMTOKEN  #REQUXRED> 

<1  ELEMENT  verb  -  o 

(  context*  )> 

< l ATTLIST  verb  %id« 

• 

# 

nan* 

CDATA 

# IMPLIED 

typ« 

CDATA 

* IMPLIED 

itemid 

CDATA 

# IMPLIED 

xref 

IDREFS 

#IMPLIED> 

<! ELEMENT  warning 

-  o  ( 

context*  ) > 

<! ATTLIST  warning 

%ids; 

name 

CDATA 

# IMPLIED 

typ« 

CDATA 

# IMPLIED 

itemid 

CDATA 

# IMPLIED 

xref 

IDREFS 

^IMPLIED 

text 

%refid; 

#REQUIRED> 

<! ELEMENT  caution 

-  o  ( 

context*  )  > 

<! ATTLIST  caution 

%ids? 

name 

CDATA 

# IMPLIED 

type 

CDATA 

# IMPLIED 

itemid 

CDATA 

# IMPLIED 

xref 

IDRF.FS 

# IMPLIED 

text 

%refid; 

#R£QUIRED> 

<! ELEMENT  note  -  o 

{  context*  )  > 

<! ATTLIST  note  %id» 

• 

f 

name 

CDATA 

# IMPLIED 

type 

CDATA 

# IMPLIED 

itemid 

CDATA 

# IMPLIED 

xref 

IDREFS 

# IMPLIED 

text 

%ref id; 

#REQUIRED> 

<! ELEMENT  annot 

-  o  ( 

context*  )  > 

<i ATTLIST  annot 

%ids; 

nane 

CDATA 

# IMPLIED 

type 

CDATA 

# IMPLIED 

itemid 

CDATA 

IIMPLIED 

xref 

IDREFS 

# IMPLIED 

text 

%refid; 

♦REQUIRED 

user 

CDATA 

#IMPLIED> 

8/23/89 


* 
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Parts  Information 


Tha  elements  "partinfo"  and  MpartbasaM  dafina  datailad  parts 
information.  "Partinfo"  dascribaa  an  itam  by  its  rafaranca 
designator  ("refdas")  which  catagorizas  parts  by  thair  place  in 
tha  system-subsystem  hierarchy.  "Partinfo"  describes  tha 
maintainor's  view  of  tha  part  information.  Each  "partinfo"  element 
is  related  to  a  "partbase"  which  describes  the  itam  in  terms  of  its 
part  number  ("partnum")  .  "Partbase"  describes  the  supply  system's 
view  of  tha  part  information.  Several  "partinfo"  items  could  be 
related  to  tha  s^me  "partbase." 

**************************************************************— •> 


< i ELEMENT 

partinfo 

-  o  (  context*  )> 

<lATTLISi 

partinfo 

%ids; 

name 

CDATA 

♦IMPLIED 

type 

CDATA 

♦IMPLIED 

itemid 

CDATA 

♦IMPLIED 

xref 

IDREFS 

♦IMPLIED 

partbase 

IDREFS 

♦REQUIRED 

refdes 

NMTOKEN 

♦REQUIRED 

nounid 

NUTOKEN 

♦IMPLIED 

nountype 

NUTOKEN 

♦IMPLIED 

unitsper 

NUTOKEN 

♦REQUIRED 

indxnum 

NUTOKEN 

♦REQUIRED 

usablon 

NUTOKEN 

♦REQUIRED 

mtbf 

CDATA 

♦REQUIRED 

raplvl 

CDATA 

♦IMPLIED 

graphic 

trefids; 

♦REQUXRED> 

<i ELEMENT  partbase 

-  o  EMPTY  > 

< ! ATTLIST  partbase 

%ids; 

name 

CDATA 

♦IMPLIED 

type 

CDATA 

♦IMPLIED 

itemid 

CDATA 

♦IMPLIED 

xref 

IDREFS 

♦IMPLIED 

partnum 

CDATA 

♦REQUIRED 

cage 

CDATA 

♦REQUIRED 

smr 

CDATA 

♦REQUIRED 

hci 

CDATA 

♦REQUIRED> 

<  J  ..«*********«•* ft************************************* *******-** 

Fault  Information 

Thr««  types  of  fault  information  can  be  described  in  the  COM:  (A) 
fnult  reporting  decision  trees,  (B)  fault  isolation  decision  trees, 
a.td  (C)  dynamic  fault  isolation  models  (such  as  AFHRn's  MDAS 
model) .  The  fault  reporting  and  isolation  decision  trees  are 
static,  predefined  decision  sequences.  A  dynamic  fault  model 
generates  the  decision  sequence  at  display  time  from  a  fault  model 
of  the  equipment.  In  the  case  of  a  decision  tree,  the  complete 
tree  is  defined  in  the  data.  In  the  case  of  a  dynamic  fault 
isolation  model,  only  the  data  needed  to  represent  the  fault  model 
of  the  equipment  is  defined  in  the  data. 

Any  of  these  diagnostic  data  structures  can  be  described  in  terms 
of  diagnostic  tests  (  "test"),  test  outcomes  ("outcome”),  fault 
states  ("fltstate") ,  repairable  faults  (  "fault"),  and  fault 
rectification  actions  ("rect") .  The  general  logic  is  that  you 
begin  a  fault  reporting  or  isolation  process  with  a  "test",  which 
may  be  as  simple  as  "what  symptoms  did  you  observe?",  or  as  a 
complex  as  a  50-step  checkout  procedure.  Each  "test"  will  have 
associated  "outcomes"  which  associate  possible  test  results  with 
new  fault  states  ("fltstate") .  Test  results  are  described  as 
"precond"  statements  (e.g.,  voltage  »  4.5v.,  light  -  dim,  faultcode 
*  A123 ,  ...  )  which  are  asserted  by  the  "test"  procedure  as  the 
test  is  performed.  The  "outcome"  elements  relate  those  possible 
test  results  to  fault  states. 

A  "fltstate"  state  represents  a  node  in  a  fault  isolation  decision 
tree  or  a  set  of  plausible  faults  in  a  dynamic  fault  model  .  A 
"fltstate" state  provides  hhe  information  necessary  to  select  the 
next  diagnostic  test.  In  a  decision  tree,  the  test  is  explicitly 
identified  by  the  "test"  attribute  of  "fltstate."  In  a  dynamic 
fault  model,  the  "test,v  is  not  explicitly  identified  (i.e.,  the 
"test"  attribute  is  empty) ,  and  the  "fltstate"  specifies  a  list  of 
implicated  faults  ("impfault")  and  a  list  of  exculpated  faults 
("expfault")  for  that  state.  Implicated  faults  are  those  which  are 
suspected  as  being  bad  in  the  fault  state.  Exculpated  faults  are 
those  known  to  be  good  in  the  fault  state.  These  fault  lists  are 
then  used  by  dynamic  software  to  generate  a  list  of  appropriate 
"tests"  which  will  further  isolate  the  list  of  implicated  faults. 
No  matter  how  the  test  is  selected,  statically  by  the  data  or 
dynamically  by  the  software,  the  selected  "test"  is  performed  and 
the  process  continues  until  a  fault  is  isolated.  In  a  decision 
troe,  a  fault  is  identified  when  you  reac.i  a  final  "fltstate"  node 
which  does  not  reference  a  "test",  but  lists  the  identified 
"fault."  In  a  dynamic  fault  model,  the  final  fault  is  identified 
by  the  software  and  is  not  explicitly  represented  in  the  "fltstate" 
element. 
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Onca  a  "fault1*  la  idantifiad,  tha  ractiflcation  (i.e. ,  rapair) 
procadura  ("ract")  aaaoclatad  with  tha  "fault"  la  performed. 
Ractiflcation  actions  alao  hava  an  aaaociata  "tast"  which  is 
generally  a  checkout  taak  to  varify  that  tha  ractiflcation  action 
succassfully  fixad  tha  problam.  Tha  "ract"  element  also  has  a 
fault  attribute  which  is  a  list  of  faults  that  identifies  all  of 
the  faults  repaired  by  tha  rectification  action. 

Tests  and  rectifications  can  be  performed  by  a  human  or  machine 
agent.  The  elements  "test"  and  "rect"  have  an  "agent"  attribute 
which  states  whether  the  action  is  performed  by  a  human  or  a 
machine. 

ft*********#*#*****#*************************************#*****— — > 


<! ELEMENT  faultinf  -  o  (  context*  )> 


faultinf 

%ids; 

name 

CDATA 

# IMPLIED 

type 

CDATA 

# IMPLIED 

itemid 

CDATA 

# IMPLIED 

xref 

IDREFS 

# IMPLIED 

test 

%refids; 

#REQUIRED 

fault 

%refids; 

#REQUIRED> 

<! —  Delated  faultrep,  faultiso,  faultmodel,  these  can  be 
represented  in  "type”  — > 


<! ELEMENT 
<i ATTLIST 


< ! ELEMENT 
<! ATTLIST 


test  -  o 
tast 

(  context*  )> 

%ids; 

name 

CDATA 

# IMPLIED 

type 

CDATA 

# IMPLIED 

itemid 

CDATA 

# IMPLIED 

xref 

IDREFS 

# IMPLIED 

text 

%refid; 

* IMPLIED 

agent 

(  human  | 

machine  )  "human 

task 

%raf ids ; 

fREQUIRED 

outcome 

%refids; 

# REQUIRED 

range 

CDATA 

#IMPLIED> 

outcome 

outcome 

-  o  (  context*  )  > 

%ids; 

name 

CDATA 

# IMPLIED 

type 

CDATA 

# IMPLIED 

itemid 

CDATA 

# IMPLIED 

xref 

IDREFS 

# IMPLIED 

text 

%refid; 

# IMPLIED 

precond 

IDREFS 

#REQUIRED 

fltstate 

% ref ids; 

#REQUIRED> 
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<1 ELEMENT  fltstata 
< ! ATTLIST  fltstata 
name 
typa 
itemid 
xraf 
text 

expfault 

impfault 

weight 

test 


<! ELEMENT  fault 
<1 ATTLIST  fault 
name 
type 
iteiaid 
xref 
mtbf 
fltstata 
text 
rect 

partinfo 


<! ELEMENT  rect  -  o 
<! ATTLIST  rect  %ids 
name 
type 
Itemld 
xraf 
action 
agent 
text 
task 
test 
fault 


-  o  (  context*  )> 

%ld# ; 

CDATA 

# IMPLIED 

CDATA 

♦'IMPLIED 

CDATA 

# IMPLIED 

IDREFS 

# IMPLIED 

%refld; 

# IMPLIED 

%reflds; 

# IMPLIED 

%ref ids ; 

# IMPLIED 

NUTOKENS 

# IMPLIED 

%refid; 

#IMFLIED> 

-  o  (  context*  ) > 
%ids; 

CDATA 

# IMPLIED 

CDATA 

# IMPLIED 

CDATA 

# IMPLIED 

IDREFS 

♦IMPLIED 

CDATA 

♦IMPLIED 

%ra fids? 

♦IMPLIED 

%refid; 

♦IMPLIED 

%refids; 

♦REQUIRED 

%refids; 

♦IMPLIED> 

(  context*  ) > 

CDATA 

♦IMPLIED 

CDATA 

♦IMPLIED 

CDATA 

♦IMPLIED 

IDREFS 

♦IMPLIED 

(  *wap  | 

maint  ) 

(  human 

|  machine  ) 

%refid; 

♦IMPLIED 

%rafids; 

♦REQUIRED 

%refids; 

♦IMPLIED 

%ref ids ; 

♦IMPLIED> 

"swap" 

"human" 
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Text  Elements 


"Text**  is  the  primitive  text  element  referenced  by  more  complex 
data  elements  in  the  CDM.  A  "textH  unit  is  basically  a  text  string 
of  "parsable  character  data"  or  PCDATA.  Within  a  text  string, 
attribute  values  ("attvaiue")  of  other  CDM  elements  may  be 
referenced  and  inserted  as  text  string.  For  example,  the  string 
may  contain  a  reference  to  a  standard  system  name,  or  a  standard 
part  nomenclature,  or  a  standard  task  name.  "Attvaiue*  may  be  used 
to  embed  one  of  these  references  in  a  string  which  tells  the 
display  system  to  find  the  value  of  the  referenced  attribute  and 
place  that  value  into  the  text  string  for  display.  By  using  this 
mechanism,  standard  terminology  can  be  referenced  consistently 
throughout  the  data  base,  and  any  changes  to  the  standard 
terminology  can  be  made  in  one  location  and  automatically  updated 
throughout  the  data  base. 

**************#*************************-********  A  **.-*************- 

-> 

*! ELEMENT  text  -  (  context*,  (  # PCDATA  |  attvaiue) +  )> 

< IATTLIST  text  %ids; 

name  CDATA  # IMPLIED 

type  CDATA  # IMPLIED 

itemid  CDATA  # IMPLIED 

xref  IDREFS  #IMPLIED  > 


< 1  ELEMENT  title  - (  context*,  (  # PCDATA  I  attvaiue  )+  ) 

> 

< IATTLIST  title  %ids; 

name  CDATA  # IMPLIED 

type  CDATA  # IMPLIED 

itemid  CDATA  # IMPLIED 

xref  IDREFS  #IMPLIED> 


ELEMENT  dictitem  -  -  (  context*)  > 

< IATTLIST  dictitem  %ids; 

name  CDATA  # REQUIRED 

type  (  gloss  |  abbsyw  J  symbol  |  other  )  "other" 
itemid  CDATA  # IMPLIED 

xref  IDREFS  # IMPLIED 

def  %refids  #REQUIR£D> 


< I ELEMENT  attvaiue  -  o  EMPTY  > 

< IATTLIST  attvaiue  elmntref  %refid?  # REQUIRED 
dttname  NAME  "name"> 
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<1 «~***«******************************^******** ************ ***** 
Element  Cross  References 

The  element  "xref"  defines  a  cross  reference  or  relational  link. 
Each  cross  reference  has  at  least  one  %refid  which  may  be  an 
internal  reference  (pointing  to  an  element  within  a  particular  CDM 
data  base)  or  an  external  reference  (pointing  to  an  element  outside 
of  the  CDM) .  internal  references  are  represented  by  "elmntref " 
which  is  a  reference  id  for  any  CDM  element.  External  references 
are  performed  by  "exrefid"  which  is  character  data  describing 
another  file  or  database  element.  All  cross  references  may  have 
a  type  ( "relation”)  which  is  a  text  string  describing  the  nature 
of  the  reference  (e.g.,  “theory,"  "I?B,"  "schematic*1-)  .  There  is 
an  optional  attribute  "attname"  which  may  be  used  to  narrow  the 
"xref"  to  a  particular  attribute  value  of  the  croas-referenced 
element. 

****************************»***********&*******.  **********  *****-- 

> 

EMPTY  > 

ID  # REQUIRED 

CDATA  # IMPLIED 

% re fids;  #IMPLIED 

NAMES  # IMPLIED 

CDATA  # IMPLIED  > 


<! ELEMENT 
< ! ATTLIST 


xref  -  o 

xref  id 

relation 

elmntref 

attname 

exrefid 
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Tables  and  Lists 

"Table,"  "colhddef, H  and  "entry"  define  the  structure  for  a  table 
of  information.  The  cells  or  "entries"  of  a  table  may  be  a  "text" 
unit  or  any  element  identified  by  an  "refid." 

A  "list"  is  a  general  purpose  structure  used  to  group  individual 
elements  into  a  list  of  elements  which  share  a  common  context. 
For  example,  if  you  wanted  to  specify  that  a  list  of  steps  were 
all  to  be  performed  if  a  certain  precondition  were  true,  you  could 
group  those  steps  into  a  list  with  a  single  context  which  specified 
the  desired  precondition. 

************************************** ***********************-»-> 
<! ELEMENT  table  -  -  (  context*)  > 


< i ATTLIST  table 

%ids; 

name 

CDATA 

# IMPLIED 

type 

CDATA 

IIMPLIED 

itemid 

CDATA 

# IMPLIED 

xref 

IDREFS 

IIMPLIED 

colhddef 

IDREFS 

f REQUIRED 

entry 

IDREFS 

♦REQUIRED 

<! ELEMENT  colhddef 

1 

-  O  EMPTY >  1 

<i ATTLIST  colhddef 

id  ID 

# REQUIRED 

name 

CDATA 

IIMPLIED 

type 

CDATA 

IIMPLIED 

colnum 

NUTOKEN 

|REQUIRED> 

<1 ELEMENT  entry 

-  O  EMPTY> 

<! ATTLIST  entry 

id  ID 

IREQUIRED 

col 

NUTOKEN 

1 REQUIRED 

row 

NUTOKEN 

IREQUIRED 

text 

%refid; 

IIMPLIED 

elmntref 

%refid; 

|IMPLIED>  ! 

j 

<! ELEMENT  list  -  O 

(  context*  )  > 

<J ATTLIST  list  %ids 

* 

9 

elmntref 

%refids; 

|REQUIRED> 

64 


Drafts  Contant  Data  Modal 


y  tea  ion.  5.1 


&J22I31 


<!- .A************************************************************ 
* 

Graphics 

Ths  COM  allows  graphics  to  bs  referenced  from  external  graphics 
filss  or  embedded  in  ths  COM  data  bass.  Ths  element  "grphprim" 
may  contain  a  "fils"  nams  which  idsntifiss  an  sxtsmal  file 
containing  a  graphic  data  in  any  of  ths  snumsratsd  formats  (cgm, 
-iges,  dxf ,  fax,  ...  ) .  Ths  sams  .graphic  data  may  also  be  included 
directly  in  the  COM  by  putting  the  data  in  the  "# PCDATA  "  content 
portion  of  a  "grphprim"  element. 

Both  "graphic"  and  "graphprim"  have  a  set  of  optional  attributes 
to  specify  transformations  (i.e.,  scaling,  translating,  rotating, 
clipping,  etc.).  A  "graphic"  or  "grphrim"  element  may.  specify  a 
transformation  matrix  ("transfrm") ,  a  clipping  "window,"  a  pen 
shape  ("penshape") ,  a  pen  pattern  ("penpatt"),  and  a  label 
("text").  Transformations  ("transfrm")  are  specified  by  a  9-number 
transformation  matrix  which  specifies  coordinate  translation, 
scaling,  reflection,  and  rotation  in  . terms  of  homogeneous 
coordinates  (see  Chapter  3  of  Rodgers,  D.F.,  and  Adams,  J.A., 
"Mathematical  Elements  For  Computer  Graphics",  McGraw  Hill,  1976, 
for  a  complete  definition  of  this  matrix) . 

Composite  graphics  may  be  constructed  by  grouping  transformed 
graphics  ("graphic"  or  "grphprim")  into  a  "graphic"  element. 
These  transformed,  labelled,  named,  and  typed  graphic  illustrations 
are  then  referenced  by  steps  and  paras  in  the  CDM.  A  composite 
"graphic"  may  also  specify  a  list  of  "focus"  objects  which  are  the 
subgraphics  of  interest  in  that  particular  illustration.  This 
attribute  could  be  used  to  specify  which  subgraphics  in  an 
illustration  are  to  be  highlighted,  labelled,  ate.,  by  the 
presentation  software. 

"Graphic"  and  "grphprim"  also  may  specify  a  minimum  size 
("minsize")  required  to  satisfactorily  display  the  graphic  to  the 
user.  The  minimum  size  is  specified  in  terms  of  the  amount  of 
visual  angle  the  graphic  image  should  subtend  on  the  eye.  This 
will  allow  different  display  systems  with  different  viewing 
distances  to  adjust  the  physical  size  of  the  graphic  to  provide 
the  correct  visual  image  as  intended  by  the  author. 
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>***_ 


-> 


<! ELEMENT  graphic 


-  o  (  context*  )> 
%ids? 


name 

CDATA 

# IMPLIED 

type 

(  normal 
schem  (  : 
.  engin  ) 

|  locat 
functblk 

( 

1 

» 

# IMPLIED 

itemid 

CDATA 

# IMPLIED 

xref 

IDREFS 

# IMPLIED 

text 

%refid; 

# IMPLIED 

focus 

%refids; 

# IMPLIED 

-graphic 

trefids; 

♦REQUIRED 

transform 

NUTOKENS 

♦IMPLIED 

window 

NUTOKENS 

♦IMPLIED 

penshape 

NUTOKENS 

♦IMPLIED 

penpatt 

NTOKEN3 

♦IMPLIED 

mmsizo 

NUTOKENS 

#IMPLXED> 

overlay 
wiring  | 


<  i  -  t graphic  was  incorporated  in  graphic  — > 


<1  ELEMENT  grphprim  -  -  (  context*,  # PCDATA  )> 

<1 ATT LIST  grphprim  %ids; 

name  COATA  # IMPLIED 

type  (  normal  |  locat  overlay  | 

schem  |  functblk  wiring  | 
engin  )  # IMPLIED 

itemid  CDATA  # IMPLIED 
xref  .  IDREFS  #  IMPLIED 
text  %refid;  #  IMPLIED 

file  CDATA  # IMPLIED 

coding  (egmehar  j  cgmbin  f  egmelear  | 

fax  |  iges  f  dxf  |  gks)  "cgmbin" 
transfrm  NUTOKENS  fIMPLIEO 
window  NUTOKENS  # IMPLIED 
penshape  CDATA  # IMPLIED 
penpatt  CDATA  # IMPLIED 
minsize  NUTOKENS  #IMPLI2D> 


Audio  -  Video  -  Process 


The  elements  "audio*’,  "video",  and  "process"  ara  rafarancas  to 
aithar  a  fila  name  or  an  axtamal  source  which  contains  an  audio 
sequence,  a  video  sequence,  or  a  software  procass,  respectively. 


*************************************************************_„.> 


< ! ELEMENT 

audio 

-  o  ( 

context*  )  > 

<! ATTLIST 

audio 

%ids; 

name 

CDATA 

1 IMPLIED 

type 

CDATA 

# IMPLIED 

itemid 

CDATA  . 

IIMPLIED 

xref 

IDREFS 

# IMPLIED 

file 

CDATA 

1 IMPLIED 

exrefid 

CDATA 

# IMPLIED  > 

< ! ELEMENT 

video 

-  o  ( 

context*  )  > 

< i ATTLIST 

video 

%ids; 

name 

CDATA 

# IMPLIED 

type 

CDATA 

# IMPLIED 

itemid 

CDATA 

IIMPLIED 

xref 

IDREFS 

IIMPLIED 

file 

CDATA 

IIMPLIED 

exrefid 

CDATA 

IIMPLIED  > 

<J ELEMENT 

procass 

-  O  ( 

context*  )  > 

<1 ATTLIST 

procass 

%ids; 

nama 

CDATA 

IIMPLIED 

type 

CDATA 

IIMPLIED 

itemid 

CDATA 

IIMPLIED 

xref 

IDREFS 

IIMPLIED 

fila 

CDATA 

IIMPLIED 

axrafid 

CDATA 

IIMPLIED  > 

< } ~-***********^****************************u********rt****** 


Prompts 

A  "prompt**  specifies  either  a  fill-in-the-blank  ("fillin")  or  menu 
choice  ("menu")  question  for  the  user.  Frompts  are  characterized 
in  terms  of  property-value  pairs  (like  assertions  and 
preconditions) .  Basically,  each  prompt  is  associated  with  a 
"property"  which  specifies  the  property  which  will  be  asserted 
along  with  the  user's  response  when  the  prompt  is  answered.  If 
the  prompt  is  a  "fillin"  the  user's  response  will  be  asserted  as 
the  "value"  of  the  specified  "property".  If  the  prompt  is  a 
"menu",  the  user's  "choice"  selection  from  the  menu  will  have  an 
associated  "value"  which  will  be  asserted  as  the  "value"  of  the 
prompt's  "property".  Once  this  assertion  is  made,  other  elements 
in  the  system  may  use  the  information  to  test  preconditions 
("precond")  concerning  the  asserted  property. 

The  "text"  of  a  prompt  is  the  question  which  will  ba  displaced  to 
the  user.  The  "text"  of  a  "choice"  is  the  menu  choice  which  will 
be  displayed  to  the  user  as  his  list  of  possible  menu  selections. 


Both  "fillin"  and  "menu"  prompts  can  have  a  "default"  value.  In 
the  case  of  a  "fillin,"  the  "default"  is  a  text  string  ( "CDATA" ) 
which  will  be  used  as  the  initial  entry  in  the  fill-in-the-fclank 
form.  In  the  case  of  a  "menu",  the  default  will  be  an  IDREF(S)  to 
one  of  the  possible  "choice"  responses. 

*************  ******************************A****£*^£ *******+**--> 


<! ELEMENT 

prompt 

-  o  (  context*  )> 

< I ATTLIST 

prompt 

%ids; 

name 

COATA 

# IMPLIED 

type 

COATA 

♦IMPLIED 

itemid 

CDATA 

♦IMPLIED 

xref 

IDREFS 

♦IMPLIED 

text 

%refid; 

♦IMPLIED 

fillin 

%ref ids ? 

♦IMPLIED 

menu 

%refids; 

♦IMFLI2D 

<! ELEMENT 

fillin 

-  o  (  context*  )  > 

<! ATTLIST 

fillin 

%ids; 

name 

CDATA 

♦IMPLIED 

type 

CDATA 

♦IMPLIED 

itemid 

CDATA 

♦IMPLIED 

xref 

IDREFS 

♦IMPLIED 

• 

text 

%refid; 

♦REQUIRED 

property 

IDREF 

♦REQUIRED 

range 

CDATA 

♦IMPLIED 

default 

CDATA 

#IMPLIED> 

<! ELEMENT  aanu  -  o  (  sontast*  )  > 

< 1 ATTLIST  nenu  %ids; 

nan*  CDATA  # IMPLIED 

typ*  CDATA  * IMPLIED 

itamid  CDATA  * IMPLIED 

xraf  IDREFS  # IMPLIED 

t*xt  %r*fid;  IREQUIRED 

proparty  IDREF  # REQUIRED 

aalact  (  aingle  j  multiple  )  "aingle" 

choica  IDREFS  # REQUIRED 

default  IDREFS  #IMPLIED> 


< ! ELEMENT  choice  -  o  EMPTY  > 

<t ATTLIST  choice  id  ID  # REQUIRED 

text  t ref id;  # REQUIRED 

value  IDREFS  #REQUIRED> 


<1  — 


Context  and  Assertions 

Evsry  CDM  composite  object  also  has  context.  Vehicle 
configuration,  security  level,  and  technician  skill  level  are 
examples  of  context  properties  which  determine  the  applicability 
of  a  particular  data  element  to  the  situation  at  hand.  "Context" 
consists  of  a  set  of  frequently  used  "affectivity"  attributes 
(security,  config,  track,  version  )  ,  and  a  list  of  user-defined 
"precond"  (preconditions  ) . 

"Precond"  and  "assertion"  are  both  defined  in  terms  cf 
property-value  pairs.  h  "property"  is  any  "text"  string  which 
defines  a  property.  A  "value"  is  another  "text"  string  defining 
the  value.  Property-value  pairs  may  be  asserted  or  tested  by  the 
run-time  presentation  software.  An  "assertion"  on  a  paragraph  or 
step  will  be  asserted  whenever  that  paragraph  or  step  is  performed. 
A  "precond"  is  a  test  of  a  property  previously  asserted.  The 
property  element  also  has  an  "elmntref"  attribute  which  is  an 
optional  attribute  which  may  be  used  to  indicate  a  prompt  or  task 
which  can  be  activated  to  acquire  a  value  for  the  property  if  none 
has  been  asserted. 

*************************************, ****«******. ***************. 
-> 

<! ELEMENT  context  -  o  EMPTY > 


context 

id  ID 

*REQUIKwD 

security 

(uc  |  c  | 

S  J  ts)  # IMPLIED 

# IMPLIED 

restrict 

NMTOKENS 

release 

NMTOKENS 

♦IMPLIED 

codeword 

NMTOKENS 

# IMPLIED 

scilevel 

NUMBER 

# IMPLIED 

diglyph 

NMTOKENS 

# IMPLIED 

config 

NMTOKENS 

# IMPLIED 

maintlvl 

CDATA 

# IMPLIED 

track 

NUTOKENS 

* IMPLIED 

version 

NUTOKENS 

# IMPLIED 

valstat 

CDATA 

# IMPLIED 

verstat 

CDATA 

# IMPLIED 

precond 

IDREFS 

#IMPLIED> 

<! ELEMENT  assertion  -  o  EMPTY> 

< i ATTLIST  assertion  id  ID  # REQUIRED 

polarity  (  pos  )  neg  )  "pos" 

property  idref  #required 

value  IDREFS  #REQUIRED> 
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<i ELEMENT  precond  *  o  EMPTY  > 

<  t  ATTLZST  pracond  id  ID  fREQUIRED 

polarity  (  poa  |  nag  )  "poa" 

proparty  IDREF  fREQUIRED 

op  (  aq  |  it  |  lta  f  gt  |  gta  |  in  ) 

valua  IDREFS  #REQUIRED> 

< i ELEMENT  proparty  -  o  EMPTY> 

< ! ATTLIST  proparty  id  ID  fREQUIRED 

taxt  trafid;  fREQUIRED 

almntref  %refid;  #IMPLIED> 

<! ELEMENT  valua  -  o  EMPTY> 

< ! ATTLIST  valua  id  ID  fREQUIRED 

text  %raf id ;  #REQUIRED> 


APPENDIX  B 


JOB  GUIDE 
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< 1 DOCTYPE  jobguide  [ 

<!  ENTITY  %  yesorno  •' NUMBER  "> 

<! ENTITY  %  bodyatt  "id  ID  #IMPLIED 
inacfclvl  NUTOKEN  # IMPLIED 
delchlvl  NUTOKEN  # IMPLIED 
label  NMTOKEN  #IMPLIED 
texttype  NUMBER  # IMPLIED 
item id  NMTOKEN  # IMPLIED 
config  NUTOKENS  # IMPLIED 
skilltrk  CDATA  # IMPLIED 
hep  %yesorno?  'O' 
xre*  IDREF  #IMPLIED"  > 

<! ENTITY  %  change  "stchg  I  endchg"  > 

<! ENTITY  %  colfmt  "colnum  NUMBER  # REQUIRED 
datatype  CDATA  #IMPLIED  “ 
left  %yesorno;  'O' 
right  %yesorno;  'O' 
center  %yesorno ;  'O' 
char  CDATA  # IMPLIED 
Width  NUMBER  # IMPLIED 
leader  CDATA  # IMPLIED 
colsep  tyeaomo;  #  IMPLIED 
rovhead  %yesomo?  *0'  "  > 

<1  ENTITY  %  contdef  "TBD"  > 

<!EN1ITY  %  def  ""  > 

<! ENTITY  %  asyntxt  "steng  |  endemg  |  %change;  |  steaph  \  endemph" 


<! ENTITY  %  list  "seqlist  |  randlist  |  def list"  > 

<! ENTITY  %  nums  "partno  |  modelno  |  sssn  |  figindex"  ^ 

<! ENTITY  %  secur  "security  (uc  j  c  |  s  |  ts)  #IMPLIED 
restrict  NMTOKENS  # IMPLIED 
release  NMTOKENS  # IMPLIED 
codeword  NMTOKENS  # IMPLIED 
scilevel  tyesorno  1 0 1 
diglyph  NMTOKENS  # IMPLIED"  > 

< ! ENTITY  %  spepara  "(warning*,  caution*,  note*)"  > 
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<1  ENTITY  \  text  H ( # PCDATA  |  tasyntxt;  |  %nums?  |  tool  |  testeq  | 
material  | 

torquevl  |  xref  |  graphic  |  subscrpt  |  supscrpt) *"  > 

<! NOTATION  iges  PUBLIC  "-//USA-DOP//NOTATION  Initial  Graphics 
Exchange 

Specification//EN"  > 

<! NOTATION  cgm  PUBLIC  " -//USA-DOD//NOTATION  Computer  Graphics 
Metaf ile//EN" 


< [NOTATION  fax  PUBLIC  " -//USA-DOD//NOTATION  CCITT  Group  4 
Facsimile//EN" 


<! NOTATION  math-eqn  PUBLIC  " -//USA-DOD//NOTATION  EQN  Mathematical 
Notation//EN"  > 

<!  NOTATION  math-t-iX  PUBLIC  " -//USA-DOD//NOTATION  TEX  Mathematical 
Notation//EN"  > 

< [NOTATION  mathsmf f  PUBLIC  ,,-//USA-DOD//NOTATION  IBM  Scientific  and 

Mathematical  Formula 
Format//EN"  > 

<! ENTITY  %  ISOlatl  PUBLIC  "ISO  8879-1986//ENTITIES  Added  Latin 
1//EN" 

> 

<[ ENTITY  %  ISOlat2  "ISO  8879-1986//ENTITIES  Added  Latin  2//EN"  > 


<! ENTITY  %  IS9grJcl  HISO  8879-1986//ENTITIES  Greek  Letters//EN"  > 


<1  ENTITY  %  ISOnum  "ISO  8879-1986//ENTITIES  Numeric  and  Special 
Graphic//EN" 


< I  ENTITY  %  ISOdia  "ISO  8879-1986//ENTITIES  Diacritical  Marks// EN" 


> 

<! ENTITY  %  ISOpub  "ISO  8879-1986//ENTITIES  Publishing//EN"  > 
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<! ENTITY  %  ISObox  "ISO  8879-1986//ENTITIES  Box  and  Line 
Drawing//EN" 

> 

<! ENTITY  %  ISOtech  "ISO  8879-1986//ENTITIES  General  Technical//EN" 

> 

<i ENTITY  %  ISOamso  "ISO  8879-1986//ENTITIES  Added  Math  Symbols: 
Ordinary//EN"  > 

<! ENTITY  %  ISOamsb  "ISO  8879-1986//ENTITIES  Added  Math  Symbols: 
Binary  Operators//EN"  > 

<! ENTITY  %  ISOamsr  "ISO  8879-1986//ENTITIES  Added  Math  Symbols: 
Relations//EN"  > 

< I ENTITY  %  ISOamsn  "ISO  8879-1986//ENTITIES  Added  Math  Symbols: 
Negated  Relations//EN"  > 

<! ENTITY  %  ISOamsa  "ISO  8879-1986//ENTITIES  Added  Math  Symbols: 
Arrow  Relations//EN"  > 

<! ENTITY  %  ISOamec  "ISO  8879-1986//ENTITIES  Added  Math  Symbols: 
Delimiters//EN"  > 

<1— ■ tISOlatl;  %IS01at2;  tlSOgrkl;  %ISOnum;  %ISOdia;  %ISOpub; 
% ISObox; 

%ISOtech;  %lSOamso;  tISOamsb? 

%ISOamsr;  %ISOamsn;  %ISOamsa;  %ISOamsc;  — > 

<! ENTITY  effdate  "The  effective  date  of  this  publication  is 
&effdatel; . 

Instructions  herein  shall  not  be  used 
prior  to  that  date."  > 

<1  ENTITY  effdatel  "Originator  Supplies  Effective  Date  Here"  > 

<! ENTITY  disclos  "If  this  technical  manual  is  approved  for  release 
to  a  foreign  government/  it  is  furnished 
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upon  the  condition  that  it  will  not  b«  released  to  anothar  nation 
without  specific  authority  of  the  Sdisclosl; 

of  the  United  States,  that  it  will  be  used  for  military  purposes 
only,  that  individual  or  corporate  rights 

originating  in  the  information,  whether  patented  or  not  will  be 
respected, 

that  the  recipient  will  report 

promptly  to  the  US,  any  known  or  suspected  compromise,  and  that  the 

information  will  be  provided  substantially  the  same  degree  of 
security 

afforded  it  by  the  Department  of  Defense  of  the  United  States."  > 


<! ENTITY  disclosi  "Originator  Supplies  Appropriate  Department  or 
Agency  Here"  > 

<1 ENTITY  pgclass  "This  publication  consists  of  Spgclassl;  secret 

pages  of  &pgclass2;  total  pages  (N) .  Copy  * 

No.  &pgclass3;  of  &pgclass4?  copies."  > 

<  l ENTITY  pgclassl  "Originator  Supplies*  Number  of  Secret  Pages  Here" 


> 

<1  ENTITY  pgclass2  "Originator  Supplies  Total'  Number  of  Pages  Here" 


> 

<! ENTITY  pgclass3  "Originator  Supplies  Number  of  This  Copy  Here" 


> 

<!  ENTITY  pgclass4  "Originator  Supplies  Total  Number  of  Copies  Here" 


> 

<! ENTITY  fouo  "For  Official  Use  Only"  > 

<! ENTITY  fcuo  "For  Consortium  Use  Only"  > 

<! ENTITY  fmuo  "For  HAP  Use  Only"  > 

< l ENTITY  distrib  "This  publication  is  required  for  official  use  or 
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for  administrative  or  operational  purposes 

only.  Distribution  is  limited  to  U.S.  Government  Agencies.  Other 

requests  for  this  document  must  be 
referred  to  Sdistribl ; . "  > 

<! ENTITY  distribl  "Originator  Supplies  Applicable  Activity  or 

Address 

Here"  > 

«l ENTITY  sprsede'  "This  manual  supersedes  &sprsedel;  dated 
&sprsede2 ; , 

which  shall  be  destroyed  in  accordance  with  applicable  security 
regulations."  > 

<1  ENTITY  sprsedel  "Originator  Supplies  Superseded  Publication 

Number 

Here"  > 

<! ENTITY  sprsede2*  "Originator  Supplies  Supersedure  Date  Here"  > 

<! ENTITY  sprpre  "This  manual  supersedes  preliminary  isprprel;  date 
&sprpre2 ; . "  > 

<! ENTITY  sprprel  "Originator  Supplies  Superseded  Preliminary 

Publication 

Number  Hare"  > 

<! ENTITY  sprpre2  "Originator  Supplies  Supersedure  Date  Here"  > 


<! ELEMENT  jobguide  -  -  (front,  body)  > 

< ! ATTLIST  jobguide  status  (revision  |  change  |  prelim  |  draft  | 

formal)  "formal" 

revno  NUMBER  "0" 
chgno  NUMBER  "0" 

%secur ;  > 

<! ELEMENT  front  -  -  (idinfo,  lep,  verstat?,  contents?,  intro?)  > 

<! ATTLIST  front  %secur;  > 

<1  ELEMENT  idinfo  -  -  (pubno+,  prepubno?,  %spcpara;,  titleblk, .  (mfr, 

contrno) +,docmfr?,  noticet,  putadate, 
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ehgdata?)  > 

< 1 ATTLIST  idinfo  %secur;  > 

<! ELEMENT  pubno  -  -  (user,  docno)  > 

<! ATTLIST  pubno  %secur;  > 

<! ELEMENT  prepubno  -  -  (user,  docno)  > 

<! ATTLIST  prepubno  %sacur;  > 

<! ELEMENT  user  -  -  (#PCDATA)> 

<! ATTLIST  user  %secur;  > 

<! ELEMENT  titleblk  -  -  (doctype,  maintlvl*,  sssnrng,  prtitle)  > 

<! ATTLIST  titleblk  %secur;  > 

< ! ELEMENT  doctype  -  -  ( %text ; ) > 

<! ATTLIST  doctype  %secur;  > 

<! ELEMENT  maintlvl  -  -  (%text;)  > 

<1 ATTLIST  maintlvl  %secur;  > 

<! ELEMENT  sssnrng  -  -  (%text;)  > 

<! ATTLIST  sssnrng  %secur;  > 

<! ELEMENT  prtitle  -  -  (nomen,  type?)  > 

<! ATTLIST  prtitle  %secur;  > 

<! ELEMENT  nomen  -  ( # PCDATA)  > 

<1 ATTLIST  nomen  %secur;  > 

< l ELEMENT  type  -  (# PCDATA)  > 

<! ATTLIST  type  %secur;  > 

<! ELEMENT  mfr  -  (# PCDATA)  > 

<1 ATTLIST  mfr  tsecur;  > 

<1  ELEMENT  docmfr - ( # PCDATA)  > 

<! ATTLIST  docmfr  %secur;  > 

<!  ELEMENT  contmo - (# PCDATA)  > 

<!  ATTLIST  contmo  %secur;  > 

<! ELEMENT  notice  -  -  ((%text;)  |  (%list;))*  > 

<1ATTLIST  notice  type  (dist  |  auth  |  offic  |  branch  j  pgclass  | 

disci  |  supersed  jeffdate  |  suppl  [  nopg  | 
noclaspg)  # IMPLIED 

%secur;  > 
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cl  ELEMENT  pubdata  -  -  ( # PCDATA)  > 
clATTLIST  pubdata  %sacur;  > 

<i ELEMENT  chgdata  -  -  (# PCDATA)  > 

<!ATTLIST  chgdata  %secur;  > 

<! ELEMENT  date  -  ( # PCDATA)  > 

clATTLIST  date  %secur;  > 

cl  ELEMENT  lap  -  o  EMPTY  > 

c l ELEMENT  verstat  -  -  (para,  (para  |  %list;  |  (%spcpara; ) ) *)  > 
clATTLIST  verstat  %secur;  > 

c! ELEMENT  contents  -  o  EMPTY  > 

cl  ELEMENT  intro - (title,  (title,  (paratext  |  abbrsect  |  symsect 

|  tctorec  I  (%list;) )+)+)  > 
clATTLIST  intro  %secur;  > 

Cl ELEMENT  seqlist  -  (title?,  item*)  > 

clATTLIST  seqlist  label  CDATA  # IMPLIED 

%secur;  > 

cl  ELEMENT  randlist (title?,  item*)  > 

clATTLIST  randlist  %secur;  > 

cl ELEMENT  deflist  -  -  (term,  def)  +  > 
clATTLIST  deflist  %secur;  > 

cl ELEMENT  item  -  -  (%text;)  > 
clATTLIST  item  %bodyatt? 

%secur;  > 

Cl  ELEMENT  symsect - (deflist)  > 

clATTLIST  symsect  %secur;  > 

cl  ELEMENT  abbrsect - (deflist)  > 

clATTLIST  abbrsect  %secur;  > 

cl  ELEMENT  term  -  -  (%text;)  > 
clATTLIST  term  %secur;  > 

cl ELEMENT  tctorec  -  -  (pubno,  title,  date?)+  > 
clATTLIST  tctorec  %secur;  > 
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<1  ELEMENT  title  -  7  (*text;)  > 

<JATTLIST  title  %secur? 

texttype  NUMBER  # IMPLIED  > 

<1  ELEMENT  def  -  -  (%text;  |  table) +  -(%list;)> 

< ! ATTIjIST  def  %secur?  > 

< l ELEMENT  paratext  -  -  (%text;  |  (%list;))*  > 

< 1 ATTLIST  paratext  %secur; 

texttype  NUMBER  # IMPLIED  > 

< ! ELEMENT  para  -  -  (%text;  |  %list;  |  (%spcpara; ) ) +  +(figure  I 
chart  |  table) > 

< ! ATTLIST  para  %bodyatt? 

%sacur;  > 

< i ELEMENT  chart  -  -  (title,  (tabdef  |  stdtable) ,  thead?,  tbody) 


! ATTLIST  chart  %bod/att? 

%secur;  > 

l ELEMENT  table  -  -  (title,  (tabdef  |  stdtable),  thead?,  tbody) 

! ATTLIST  table  %bodyatt; 

tsecur;  > 

<! ELEMENT  stdtable  -  o  EMPTY  > 

<! ATTLIST  stdtable  name  ENTITY  # REQUIRED 

%secur;  > 

<1 ELEMENT  tabdef  -  -  (colbddef ) *  > 

<! ATTLIST  tabdef  siderule  %yesorno;  "0" 

colsep  lyesomo;  J,o” 
rowsep  tyesorno;  "0” 
orient  (port  |  land)  "port” 
width  (page  I  column)  "page” 

%secur;  > 

<! ELEMENT  colbddef  -  o  EMPTY  > 

<! ATTLIST  colbddef  %colfmt;  > 

<i ELEMENT  thead  -  -  (rov+)  > 

<! ATTLIST  thead  %secur;  > 


80 


Draft  Jobguide  DTD 


Varsion  6.0 


10/27/89 


<! ELEMENT  tbody  -  -  (row*)  > 

< l ATTLIST  tbody  %secur;  > 

<1 ELEMENT  row  -  -  (entry*)  > 

<1 ATTLIST  row  number  NUMBER  # REQUIRED 

rowsep  %yesorno;  # IMPLIED 
%secur?  > 

<1  ELEMENT  entry  -  -  (%text;)  -(figure  |  table  |  chart) > 

<! ATTLIST  entry  col  NUTOKEN  #REQUIRED 

row  NMTOKEN  # CURRENT 

rotate  NUMBER  "0" 

%secur;  > 

<! ELEMENT  figure  -  -  (graphic*,  title,  legend?)  > 

<! ATTLIST  figure  %bodyatt? 

%secur?  > 

<! ELEMENT  legend  -  (deflist)  > 

<1 ATTLIST  legend  %secur;  > 

< I  ELEMENT  body  -  -  (sectionl*,  section*)  +(figure  |  table  |  chart)> 

<;! ATTLIST  body  %secur;  > 

<! ELEMENT  sectionl  -  -  (title,  (title?,  (paratext  | (%spcpara;)  | 

%list;)+)*)  + (figure  |  table  j  chart) > 

<! ATTLIST  sectionl  %bodyatt; 

%secur;  > 

i 

< l ELEMENT  section  -  -  (title,  incond,  taskinfo+,endcond*, 

followon*) 

+ (figure  |  table  |  chart) > 

<! ATTLIST  section  tbodyatt; 

%secur; 

sssn  CDATA  # REQUIRED  > 

<1 ELEMENT  incond  -  -  (applic,  reqdcond?,  persreq?,  sppteqpt?, 
spptdata? , 

supplies?,  safecond?,clreq?)  > 

< I ATTLIST  incond  %bodyatt; 

%secur?  > 

< l ELEMENT  applic  -  -  (paratext*,  config*)  > 

<J ATTLIST  applic  %bodyatt; 

%secur ;  > 
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<1  ELEMENT  reqdcond  -  -  (paratext)*  > 

< ! ATTLIST  raqdcond  tbodyatt; 

%sacur;  > 

<1 ELEMENT  parsraq  -  -  (paratext*)  > 

<! ATTLIST  parsraq  %bodyatt; 

%secur;  > 

<! ELEMENT  spptaqpt  -  -  (paratext)*  > 

<! ATTLIST  spptaqpt  %bodyatt; 

*secur;  > 

<!ELEMENT  spptdata  -  -  (paratext)*  > 

<! ATTLIST  spptdata  %bodyatt; 

%secur;  > 

<! ELEMENT  supplies  -  -  (paratext*  |  table)  > 

<! ATTLIST  supplies  %bodyatt; 

%secur;  > 

<! ELEMENT  safecond  -  -  ( (%spcpara; ) ,  paratext*)  > 

<! ATTLIST  safecond  %bodyatt; 

%secur;  > 

<1 ELEMENT  clreq  -  -  (paratext*)  > 

<! ATTLIST  clraq  %bodyatt; 

%aacur;  > 

<i ELEMENT  taskinfo  -  -  (title,  (stepgrp  |  stepl)*)  > 

<! ATTLIST  taskinfo  tbodyatt; 

%secur;  > 

< l ELEMENT  stepgrp  -  -  (tspcpara,  stepl,  stepl*)  > 

<! ATTLIST  stepgrp  %bodyatt; 

%secur;  > 

<! ELEMENT  stepl  -  -  ( (%spcpara ; ) ,  paratext*,  (step2)*)  > 
<! ATTLIST  Ttapl  %bodyatt; 

%secur; 

ipi  NAME  # IMPLIED 
person  NAME  # IMPLIED  > 

<! ELEMENT  step2  -  -  ( (tspcpara; ) ,  paratext*,  (step3)*)  > 
<J ATTLIST  stap2  tbodyatt; 

%secur ; 

ipi  NAME  # IMPLIED 
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parson  NAME  # IMPLIED  > 

<j ELEMENT  stap3  -  -  ( (%spcpara;) ,  paratext+)  > 

< l ATTLIST  stap3  %bodyatt; 

Isacur; 

ipi  NAME  # IMPLIED 
person  NAME  # IMPLIED  > 

<J ELEMENT  endcond  -  -  (paratext*)  > 

<! ATTLIST  endcond  Isecur;  > 

< i ELEMENT  foilowon  -  -  (paratext*,  (%spcpara;))  > 

< l ATTLIST  foilowon  %secur;  > 

<! ELEMENT  figindex  -  -  ( # PCDATA)  > 

<! ATTLIST  figindex  %secur;  > 

<! ELEMENT  dccno  -  (# PCDATA)  > 

<! ATTLIST  docno  %secur;  > 

<! ELEMENT  sssn  -  -  ( # PCDATA)  > 

<i ATTLIST  sssn  %secur;  > 

<! ELEMENT  tool  -  (# PCDATA)  > 

<1 ATTLIST  tool  %secur?  > 

<i ELEMENT  tea teg  -  (# PCDATA)  > 

<1 ATTLIST  taatag  %sacur;  > 

<! ELEMENT  material  -  -  (# PCDATA)  > 

<1 ATTLIST  material  %secur;  > 

<1  ELEMENT  torquevl  -  -  {# PCDATA)  > 

< l ATTLIST  torquevl  %secur;  > 

<! ELEMENT  stchg  -  o  EMPTY  > 

<! ATTLIST  stchg  level  NUMBER  # IMPLIED 

status  (.add  |  delete)  # IMPLIED 
%secur;  > 

<! ELEMENT  endchg  -  o  EMPTY  > 

<! ATTLIST  endchg  level  NUMBER  # IMPLIED 

status  (add  j  delete)  # IMPLIED 
%aecur ;  > 

<! ELEMENT  subscrpt  -  -  (#PCDATA,  subscrpt?,  supscrpt?)  > 
<! ATTLIST  subscrpt  %secur;  > 
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<! ELEMENT  supscrpt  -  -  ( # PCDATA,  subscrpt?,  aupacrpt?)  > 
< l ATTLIST  aupacrpt  %aacur;  > 

<1—  8/4/89  config  changed  here  -  now  same  as  fault  — > 

<! ELEMENT  config  -  ( # PCDATA)  > 

<! ATTLIST  config  code  CDATA  # REQUIRED 

%secur:  > 

<! ELEMENT  xref  -  O  EMPTY  > 

<! ATTLIST  xref  xref  CDATA  # REQUIRED 

config  NUTOKENS  #IMPLIED 
%secur;  > 

<! ELEMENT  graphic  -  o  EMPTY  > 

<! ATTLIST  graphic  boardno  CDATA  # REQUIRED 

Width  NUTOKEN  # IMPLIED 
depth  NUTOKEN  # IMPLIED 
window  CDATA  # IMPLIED 
hscale  NUTOKEN  # IMPLIED 
vscale  NUTOKEN  # IMPLIED 
text  CDATA  # IMPLIED 
rotation  NUMBER  "0" 

%secur;  > 

! ELEMENT  partno  -  -  ( # PCDATA)  > 

I ATTLIST  partno  %secur?  > 


! ELEMENT  modelno  -  -  (# PCDATA)  > 

! ATTLIST  modelno  %secur;  > 

! ELEMENT  warning  -  (graphic?,  (parataxt*) )  > 

! ATTLIST  warning  name  ENTITY  #CONREF 
type  NAME  # IMPLIED 
xref  IDREF  # IMPLIED 
vital  (y  |  n)  "n" 

%secur;  > 

<! ELEMENT  caution  -  -  (graphic?,  (paratext*) )  > 
<1 ATTLIST  caution  name  ENTITY  #C0NREF 

type  NAME  # IMPLIED 
xref  IDREF  # IMPLIED 
%secur ;  > 

< l ELEMENT  note  -  -  (graphic?,  (paratext*))  > 

<i ATTLIST  note  name  ENTITY  fCONREF 

type  NAME  # IMPLIED 
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xref  IDREF  # IMPLIED 
%secur;  > 

<! ELEMENT  sting  -  o  EMPTY  > 

< ! ELEMENT  endemg  -  o  EMPTY  > 

<! ELEMENT  stemph  -  o  EMPTY  > 

<! ATTLIST  stemph  type  NUMBER  # REQUIRED  > 

<! ELEMENT  endemph  -  o  EMPTY  > 

< ! ATTLIST  endemph  type  NUMBER  # REQUIRED  > 

]> 


I 
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< ! DOCTYPE 

<1 ENTITY 
< l ENTITY 
<1 ENTITY 
< ! ENTITY 
< ! ENTITY 
enderaph  | 
config" 

< ! ENTITY 
< ! ENTITY 
< ! ENTITY 
< ! ENTITY 

I 

torquevl 

subscrpt 

< 1  ELEMENT 
< ! ATTLIST 


<! ELEMENT 
contents? , 
<1 ATTLIST 
# IMPLIED 


<! ELEMENT 


<! ATTLIST 
# IMPLIED 


<! ELEMENT 
<! ATTLIST 
# IMPLIED 


faultiso 


%  yesorao 
%  change 
%  contdef 
%  def 
%  asyntxt 


"NUMBER"  > 

"stchg  |  endchg"  > 
"TBD"  > 


"stemg  [  endamg  |  %change;  |  sternph 


%  list  "seqlist  j  randlist  |  deflist"  > 

%  nums  "partno  |  model no  |  sssn  |  figindex"  > 

%  spcpara  "(warning*,  caution*,  note*)"  > 

%  text  "  %asyntxt;  |  %nums;  |  tool  |  testeq  |  material 

xref  j  graphic  | 
supscrpt"  > 

faultiso  -  -  (front,  body)  +(%text;)> 

faultiso  •  status  (revision  |  change  | 


revno 

chgno 

security 

restrict 

release 

codeword 

scilevel 

diglyph 


prelim  |  draft 
NUMBER 
NUMBER 

Y  (uc  |  c  | 
t  NMTOKENS 
NMTOKENS 
d  NMTOKENS 
1  %yesorno ; 
NMTOKENS 


formal) 

•»0" 


front  -  - 

loi,  lot,  intro?) > 

front  security 

restrict  NMTOKENS 
release  NMTOKENS 
codeword  NMTOKENS 
scilevel  %yesorno; 
diglyph  NMTOKENS 


"formal" 

••0" 

# IMPLIED 
# IMPLIED 
# IMPLIED 
# IMPLIED 

#IMPLIED> 


(idinfo,  lap,  verstat?, 


idinfo 


idinfo 

restrict 

release 

codeword 

scilevel 

diglyph 

pubno 

pubno 


-  -  (pubno+,  prepubno?, 

%spcpara;,  titleblk, 

(mfr,  contrno+)+, 
docmfr?,  notice*, 
pubdate ,  chgdate? ) > 
security  (uc  I  c  J  ! 


# IMPLIED 
# IMPLIED 
# IMPLIED 

#IMPLIED> 


NMTOKENS  # IMPLIED 

NMTOKENS  # IMPLIED 

NMTOKENS  # IMPLIED 

%yesorno;  "0" 

NMTOKENS  #IMPL.TFP> 

-  -  (user,  docno)> 

security  (uc  I  c  |  s  I  t 


restrict  NMTOKENS 


♦IMPLIED 
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.*)!■<,  f-n 


release 

NMTOKENS 

♦IMPLIED 

codeword 

NMTOKENS 

♦IMPLIED 

scilevel 

lyesomo ; 

"0" 

diglyph 

NMTOKENS 

♦IMPLIED> • 

<1  ELEMENT 

prepubno 

-  -  (user, 

docno) > 

< 1 ATTLIST 

prepubno 

security 

(UC  I  C  1  3  1  ts) 

# IMPLIED 

'1  1  |  ww  f 

restrict 

NMTOKENS 

♦IMPLIED 

release 

NMTOKENS 

♦IMPLIED 

codeword 

NMTOKENS 

♦IMPLIED 

sc i level 

%yesorno; 

"0" 

diglyph 

NMTOKENS 

♦IMPLIED> 

<  1  ELEMENT 

user 

-  ( #PCDATA) > 

< ! ATTLIST 

user 

security 

( UC  1  c  1  s  I  ts) 

# IMPLIED 

1  1  1  / 

restrict 

NMTOKENS 

♦IMPLIED 

release 

NMTOKENS 

♦IMPLIED 

codeword 

NMTOKENS 

♦IMPLIED 

scileval 

%yesorno; 

”0" 

diglyph 

NMTOKENS 

#IMPLIED> 

< ! ELEMENT 

titleblk 

-  -  (doctype,  maintlvl*. 

sssnrng,  prtitle)> 

<! ATTLIST 

titleblk 

security 

(uc  1  c  1  s  1  ts) 

# IMPLIED 

restrict 

NMTOKENS 

♦IMPLIED 

release 

NMTOKENS 

♦IMPLIED 

codeword 

NMTOKENS 

♦IMPLIED 

scilevel 

%yesomo ; 

"0” 

diglyph 

NMTOKENS 

♦IMPLIED> 

< l ELEMENT 

doctype 

-  ( # PCDATA) > 

<! ATTLIST 

doctype 

security 

uc  I  c  i  s  I  ts) 

♦IMPLIED 

1  1  1  / 

restrict 

NMTOKENS 

♦IMPLIED 

release 

NMTOKENS 

♦IMPLIED 

codeword 

NMTOKENS 

♦IMPLIED 

scilevel 

%yesomo; 

IIQW 

diglyph 

NMTOKENS 

#IMPLTEn> 

<i ELEMENT 

maintlvl 

-  ( ♦PCDATA) > 

<! ATTLIST 

rraintlvl 

security 

(UC  I  c  I  s  I  ts) 

♦IMPLIED 

restrict 

NMTOKENS 

♦IMPLIED 

release 

NMTOKENS 

♦IMPLIED 

codeword 

NMTOKENS 

♦IMPLIED 

scilevel 

%yesorno; 

”0" 

diglyph 

NMTOKENS 

♦IMPLIED> 

<! ELEMENT 

sssnrag 

-  -  ( # PCDATA) > 

< ! ATTLIST 
♦IMPLIED 

sssnrng 

security 

(UC  |  C  |  s  j  ts) 

restrict 

NMTOKENS 

♦IMPLIED 

release 

NMTOKENS 

♦IMPLIED 

codeword 

NMTOKENS 

♦IMPLIED 

scilevel 

%yesorno; 

••0" 

diglyph 

NMTOKENS 

♦IMPLIED> 

<! ELEMENT 

prtitle 

-  -  (nomen, 

type?) > 
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< l ATTLIST 
# IMPLIED 


C ELEMENT 
<i ATTLIST 
# IMPLIED 


< ! ELEMENT 
< ! ATTLIST 
♦ IMPLIED 


< ! ELEMENT 
<! ATTLIST 
# IMPLIED 


<! ELEMENT 
<! ATTLIST 
♦IMPLIED 


<J ELEMENT 
<! ATTLIST 
♦IMPLIED 


<! ELEMENT 
<! ATTLIST 


prtitle 

security 

(uc  | 

c  |  •  |  ta) 

restrict 

NMTOKENS 

♦IMPLIED 

release 

NMTOKENS 

♦IMPLIED 

codeword 

NMTOKENS 

♦IMPLIED 

scilevel 

%yesorno; 

WQ" 

diglyph 

NMTOKENS 

♦IMPLIED> 

nomen 

-  ( ♦PCDATA) > 

nomen 

security 

(uc  1 

c  |  s  j  ts) 

restrict 

NMTOKENS 

♦IMPLIED 

release 

NMTOKENS 

♦IMPLIED 

codeword 

NMTOKENS 

♦IMPLIED 

scilevel 

tyesomo; 

"Q" 

diglyph 

NMTOKENS 

♦IMPLIED> 

type 

-  -  (# PCDATA) > 

type 

security 

(UC  j 

c  |  s  |  ts 

restrict 

NMTOKENS 

♦IMPLIED 

release 

NMTOKENS 

♦IMPLIED 

codeword 

NMTOKENS 

♦IMPLIED 

scilevel 

lyesorno ; 

"0” 

diglyph 

NMTOKENS 

♦IMPLIED> 

infr 

-  -  ( ♦PCDATA) > 

mfr 

security 

(uc  I 

c  |  s  |  ts 

restrict 

NMTOKENS 

♦IMPLIED 

release 

NMTOKENS 

♦IMPLIED 

codeword 

NMTOKENS 

♦IMPLIED 

scilevel 

%yesomo ; 

"0" 

diglyph 

NMTOKENS 

♦IMPLIED> 

docmfr 

-  (♦PCDATA)  > 

docmfr 

security 

(uc  1 

c  |  s  |  ts 

restrict 

NMTOKENS 

♦IMPLIED 

release 

NMTOKENS 

♦IMPLIED 

codeword 

NMTOKENS 

♦IMPLIED 

scilevel 

%yesorno; 

"0" 

diglyph 

NMTOKENS 

♦IMFLIED> 

contrno 

-  ( ♦PCDATA) > 

contmo 

security 

(uc  I 

c  |  s  |  ts; 

restrict 

NMTOKENS 

♦IMPLIED 

release 

NMTOKENS 

♦IMPLIED 

codeword 

NMTOKENS 

♦IMPLIED 

scilevel 

%yesorno ; 

»0" 

diglyph 

NMTOKENS 

#IMPLIED> 

notice 

-  ( ♦PCDATA) > 

notice  type 

(dist  1  auth  1  offic 

1 

branch  |  pgclass  j 

disci  |  supersed  | 
effdate  |  suppl  |  nopg  | 
noclaspg)  ♦IMPLIED 

security  (uc  |  c  |  s  |  ts)  # IMPLIED 
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restrict 

NMTOKENS 

# IMPLIED 

release 

NMTOKENS 

♦  IMPLIED' 

codeword 

NMTOKENS 

♦IMPLIED 

scilevel 

%yesomo ; 

**0" 

diglyph 

NMTOKENS 

♦IMPLIED> 

< ! ELEMENT 

pubdate 

-  (# PCDATA) > 

< ! ATTLIST 

pubdate 

security 

(uc  1 

c  |  s  | 

# IMPLIED 

restrict 

NMTOKENS 

♦IMPLIED 

release 

NMTOKENS 

♦IMPLIED 

codeword 

NMTOKENS 

♦IMPLIED 

scilevel 

%yesorno? 

IIQ't 

diglyph 

NMTOKENS 

#IMPLIED> 

<! ELEMENT  chgdate  -  -  (# PCDATA) > 

<!  ATT  LI  ST  chgdate  security  (uc  |  c  |  s  |  ts) 

# IMPLIED 


restrict 

NMTOKENS 

♦IMPLIED 

release 

NMTOKENS 

♦IMPLIED 

codeword 

NMTOKENS 

♦IMPLIED 

scilevel 

%yesorno? 

**  0  '* 

diglyph 

NMTOKENS 

♦IMPLIED> 

< ! ELEMENT 

date 

-  -  ( ♦PCDATA) > 

<! ATTLIST 

date 

security 

(uc  |  c  1  s  |  ts^ 

♦IMPLIED 

restrict 

NMTOKENS 

♦IMPLIED 

release 

NMTOKENS 

♦IMPLIED 

codeword 

NMTOKENS 

♦IMPLIED 

scilevel 

tyesomo ; 

i»0» 

diglyph 

NMTOKENS 

♦IMPLIED> 

<1 ELEMENT 

lep 

-  o  EMPTY > 

<1  ELEMENT 

loi 

-  o  EMFTY> 

<! ELEMENT 

lot 

-  o  EMPTY> 

<! ELEMENT 

verstat 

-  -  (para, 

(para  |  tlist;  | 

(%spcpara;))*)> 

<! ATTLIST 

verstat 

security 

(uc  |  c  |  s  |  ts; 

♦IMPLIED 

restrict 

NMTOKENS 

♦IMPLIED 

release 

NMTOKENS 

♦IMPLIED 

codeword 

NMTOKENS 

♦IMPLIED 

scilevel 

%yesomo ; 

"0" 

diglyph 

NMTOKENS 

♦IMPLIED> 

<! ELEMENT 

contents 

-  o  EMPTY > 

<! ELEMENT 

intro 

-  -  (title, 

(title,  (paratext 

abbrsect  symsect 

tctorec 

(%list, •))+)+)> 

<! ATTLIST 

intro 

security 

(uc  |  c  |  s  |  ts 

♦IMPLIED 

’•estrict 

NMTOKENS 

♦IMPLIED 

release 

NMTOKENS 

♦IMPLIED 

codeword 

NMTOKENS 

♦IMPLIED 

scilevel 

lyesorno; 

"0" 

diglyph 

NMTOKENS 

♦IMPLIED> 

<! ELEMENT 

seqlist 

-  (title? 

,  item*)> 
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label 


CDATA 


<1ATTLIST 
I IMPLIED 


<! ELEMENT 
< ! ATTLIST 
# IMPLIED 


< ! ELEMENT 
<‘,  ATTLIST 
# IMPLIED 


<! ELEMENT 
<! ATTLIST 


<! ELEMENT 
<! ATTLIST 
# IMPLIED 


saqlist 

security 

lestrict 

release 

codeword 

scilevel 

diglyph 

randlist 

randlist 


restrict 

release 

codeword 

scilevel 

diglyph 

deflist 

deflist 


restrict 

release 

codeword 

scilevel 

diglyph 

item 

item  id 

security 
restrict 

release 

codeword 

scilevel 

diglyph 

symsect 

symsect 


(UC  I  o  I  •  I 
NMTOKENS 
NMTOKENS 
NMTOKENS 
lyesomo; 
NMTOKENS 
-  -  (title? 
security 


ts)  #  IMPLIED 
# IMPLIED 
♦IMPLIED 
♦IMPLIED 

r*0« 

#IMPLIED> 
item*) > 

(uc  |  c  J  s  |  ts) 


NMTOKENS 

♦IMPLIED 

NMTOKENS 

♦IMPLIED 

NMTOKENS 

♦IMPLIED 

tyesorno ; 

••0" 

NMTOKENS 

♦IMPLIED> 

-  -  (term, 

def ) +> 

security 

(uc  | 

c  |  s  |  ts) 

NMTOKENS 

♦IMPLIED 

NMTOKENS 

♦IMPLIED 

NMTOKENS 

♦IMPLIED 

%yesorno ; 

"O" 

NMTOKENS 

♦IMPLIED> 

(♦PCDATA  |  %text ; ) +> 

ID 

♦IMPLIED 

(uc  |  c  |  s 

1  ts) 

♦IMPLIED 

NMTOKENS 

♦IMPLIED 

NMTOKENS 

♦IMPLIED 

NMTOKENS 

♦IMPLIED 

tyesorno ; 

MQN 

NMTOKENS 

♦IMPLIED> 

-  -  (deflist) > 

security  (uc  |  c  |  s  |  ts) 


restrict 

NMTOKENS 

♦IMPLIED 

release 

NMTOKENS 

♦IMPLIED 

codeword 

scilevel 

NMTOKENS 

%yesomo;  "0" 

♦IMPLIED 

< ! ELEMENT 

diglyph 

NMTOKENS 

♦IMPLIED> 

abbrsect 

-  -  (deflist) > 

<! ATTLIST 

abbrsect 

security  (uc  1 

c  1  s  1 

♦IMPLIED  ’ 

restrict 

NMTOKENS 

♦IMPLIED 

release 

NMTOKENS 

♦IMPLIED 

codeword 

scilevel 

NMTOKENS 

%yesorno;  "0" 

♦IMPLIED 

<! ELEMENT 

diglyph 

NMTOKENS 

♦IMPLIED> 

term 

-  ( ♦PCDATA) > 

<! ATTLIST 

term 

security  (uc  1 

c  1  s  1 

♦IMPLIED  ' 

restrict 

NMTOKENS 

♦IMPLIED 

release 

NMTOKENS 

♦IMPLIED 

codeword 

NMTOKENS 

♦IMPLIED 

ts) 


ts) 


I  r*lf-\4vTniv‘TirM 


l.  dtp 


scilevel 

tyesomo ; 

MQM 

diglyph 

NMTOKENS 

#IMPLIED> 

<1 ELEMENT 

tctorec 

-  -  (pubno, 

title, 

date?)+> 

< ! ATTLIST 

tctorec 

security 

(uc  | 

c  1  •  1  ts) 

# IMPLIED 

restrict 

NMTOKENS 

♦IMPLIED 

release 

NMTOKENS 

♦IMPLIED 

codeword 

NMTOKENS 

♦IMPLIED 

scilevel 

%yesomo ; 

"0" 

diglyph 

NMTOKENS 

♦IMPLIED> 

< ! ELEMENT 

title 

-  (# PCDATA )> 

< ! ATTLIST 

title 

security 

(uc  | 

c  |  s  |  ts) 

♦IMPLIED 

restrict 

NMTOKENS 

♦IMPLIED 

release 

NMTOKENS 

♦IMPLIED 

codeword 

NMTOKENS 

♦IMPLIED 

scilevel 

%yesorno; 

"0" 

texttype 

NUMBER 

♦IMPLIED 

diglyph 

NMTOKENS 

♦IMPLIED> 

< i ELEMENT 

def 

-  -  ( # PCDATA  |  paratext  |  table) +; 

<! ATTLIST 

def 

security 

(uc  1 

c  |  s  j  ts) 

# IMPLIED 

restrict 

NMTOKENS 

♦IMPLIED 

release 

NMTOKENS 

♦IMPLIED 

codeword 

NMTOKENS 

♦IMPLIED 

scilevel 

lyesorno; 

»0" 

diglyph 

NMTOKENS 

♦IMPLIED> 

< 1  ELEMENT 

paratext 

-  (# PCDATA 

j  %text ;  j  (%list;))+> 

<! ATTLIST 

paratext 

security 

(uc  | 

c  |  s  |  ts) 

♦IMPLIED 

config 

NUTOKENS 

♦IMPLIED 

restrict 

NMTOKENS 

♦IMPLIED 

release 

NMTOKENS 

♦IMPLIED 

codeword 

NMTOKENS 

♦IMPLIED 

scilevel 

%yesomor 

»0" 

diglyph 

NMTOKENS 

♦IMPLIED 

texttype 

NUMBER 

♦IMPLIED> 

<! ELEMENT 

para 

-  -  ( (%spcpara?) ,  (# PCDATA  j 

( %text ; ) )+) > 

<! ATTLIST 

para 

id  ID 

♦IMPLIED 

inschlvl 

NUTOKEN 

♦IMPLIED 

delchlvl 

NUTOKEN 

♦IMPLIED 

label 

NMTOKEN 

♦IMPLIED 

texttype 

NUMBER 

♦IMPLIED 

itezaid 

NMTORE1I 

♦IMPLIED 

config 

NUTOKENS 

♦IMPLIED 

skilltrk 

COATA 

♦IMPLIED 

hep 

*yesorno ; 

"0" 

xref 

IDKEF 

♦IMPLIED 

security 

(uc  |  c  |  s  ; 

ts) 

♦IMPLIED 

restrict 

NMTOKENS 

♦IMPLIED 
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"0" 


#  IMPLIED 
# IMPLIED 


<1  ELEMENT 


< ! ATTLIST 


< ! ELEMENT 
<i ATTLIST 
#REQUIRED 


<! ELEMENT 
<! ATTLIST 


<! ELEMENT 
<1 ATTLIST 
#REQUIRED 


release  NMTOKENS 

codeword  NMTOKENS 
scilevel  lytsomo;  "0" 

diglyph  NMTOKENS 

tabla  -  -  (title,  (tabdef 

stdtabla) ,  thead?, 
tbody) > 


#IMPLIED> 


tabla 


id 


ID 


inschlvl 

NUTOKEN 

♦IMPLIED 

delchlvl 

NUTOKEN 

♦IMPLIED  ■ 

label 

NMTOKEN 

♦IMPLIED 

texttype 

NUMBER 

♦IMPLIED 

itemid 

NMTOKEN 

♦IMPLIED 

config 

NUTOKENS 

♦IMPLIED 

skilltrk 

CDATA 

♦IMPLIED 

hep 

%yesorno; 

»*0" 

xref 

IDREF 

♦IMPLIED 

security 

(uc  |  c  |  s  | 

ts) 

♦IMPLIED 

restrict 

NMTOKENS 

♦IMPLIED 

release 

NMTOKENS 

♦IMPLIED 

codeword 

NMTOKENS 

♦IMPLIED 

scilevel 

^yesorno? 

”0" 

diglyph 

NMTOKENS 

♦IMPLIED> 

stdtabla  -  o  EMPTY > 

stdtabla  name  ENTITY 


security 

restrict 

release 

codeword 

scilevel 

diglyph 

tabdef 


s 


ts) 


tabdef 


(uc  I  c  I 
NMTOKENS 
NMTOKENS 
NMTOKENS 
%yesorno ; 

NMTOKENS 

(colbddef ) +> 


non 


siderule 


# IMPLIED 
♦IMPLIED 
♦IMPLIED 
♦IMPLIED 

♦IMPLIED> 

linn 


colsep 

%yesorno ; 

"0" 

rowsep 

%yesorno; 

"0" 

orient 

(port  |  land) 

"port 

If 

width 

(page  |  column) 

"page 

security 

(uc  |  c  |  s  | 

ts) 

♦IMPLIED 

restrict 

NMTOKENS 

♦IMPLIED 

release 

NMTOKENS 

♦IMPLIED 

codeword 

NMTOKENS 

♦IMPLIED 

scilevel 

%yesorno; 

•*0" 

diglyph 

NMTOKENS 

♦IMPLIED> 

colbddef 


-  o 

colnum 


EMPTY> 

NUMBER 


datatype 

CDATA 

♦IMPLIED 

left 

%yesorno ; 

"0" 

right 

%yesorno; 

n0n 

center 

%yesorno ; 

•*0" 

char 

CDATA 

♦IMPLIED 

width 

NUMBER 

♦IMPLIED 

leader 

CDATA 

♦IMPLIED 

colsep 

lyaaorno ; 

♦IMPLIED 

rowhaad 

%yesorao ; 

"0" 

> 

<1 ELEMENT 

thead 

-  -  ( row+ ) > 

<1 ATTLIST 

thaad 

security 

(uc  | 

c  I  s  1  ts) 

# IMPLIED 

rastrict 

NMTCKENS 

♦IMPLIED 

ralaasa 

NMTOKENS 

♦IMPLIED 

coda word 

NMTOKENS 

♦IMPLIED 

scilaval 

%yesorno ; 

"0" 

diglyph 

NMTOKENS 

#IMVLIED> 

< ! ELEMENT 

tbody 

-  -  ( row+ ) > 

< ! ATTLIST 

tbody 

security 

(uc  1 

c  1  s  I  ts) 

♦ IMPLIED 

rastrict 

NMTOKENS 

♦IMPLIED 

ralaasa 

NMTOKENS 

♦IMPLIED 

codeword 

NMTOKENS 

♦IMPLIED 

scilavel 

%yesorno ; 

”0" 

diglyph 

NMTOKENS 

♦IMPLIFD> 

< ! ELEMENT 

row 

-  -  (entry+) > 

<! ATTLIST 

row  number 

NUMBER 

♦REQUIRED 

rowsep 

%yesorno; 

♦IMPLIED 

security 

(uc  |  c  j 

S  |  ts) 

♦IMPLIED 

restrict 

NMTOKENS 

♦IMPLIED 

release 

NMTOKENS 

♦IMPLIED 

codeword 

NMTOKENS 

♦IMPLIED 

scilavel 

tyesorno ; 

«0" 

diglyph 

NMTOKENS 

♦  IMPLIEO 

< ! ELEMENT 

entry 

-  -  (IPCDATA)  +(%list;  j  warning  | 

caution  |  note)> 

<! ATTLIST 

entry  col 

NUTOKEN 

♦REQUIRED 

row 

NMTOKEN 

♦CURRENT 

rotate 

NUMBER 

"0" 

security 

(uc  |  c  | 

s  I  ts) 

♦IMPLIED 

rastrict 

NMTOKENS 

♦IMPLIED 

ralaasa 

NMTOKENS 

# IMPLIED 

codeword 

NMTOKENS 

♦IMPLIED 

scilaval 

%yesorno ; 

"0" 

diglyph 

NMTOKENS 

♦IMPLIED> 

<! ELEMENT 

causedby 

-  ( IPCDATA,  item-*)  > 

<! ELEMENT 

figure 

-  -  (graphic* ,  title. 

legend?) > 

< ! ATTLIST 

figure  id 

ID 

♦IMPLIED 

inschlvl 

NUTOKEN 

♦IMPLIED 

dalchlvl 

NUTOKEN 

♦IMPLIED 

label 

NMTOKEN 

♦IMPLIED 

texttype 

NUMBER 

♦IMPLIED 

itemid 

NMTOKEN 

♦IMPLIED 

config 

NUTOKENS 

♦IMPLIED 

skilltrk 

CDATA 

♦IMPLIED 

hep 

%yesorno ; 

"0" 

jaref 

IDREF 

♦IMPLIED 

security 

(uc  |  c  |  c  | 

ts) 

♦IMPLIED 

restrict 

NMTOKENS 

♦IMPLIED 

release 

NMTOKENS 

♦IMPLIED 

codeword 

NMTOKENS 

♦IMPLIED 

scilevel 

%yesomo ; 

"0" 

diglyph 

NMTOKENS 

♦IMPLIED> 

<1  ELEMENT 

legend 

-  -  (deflist)> 

<! ATTLIST 

legend 

security 

(uc  1 

c  |  s  | 

♦IMPLIED 

restrict 

NMTOKENS 

♦IMPLIED 

release 

NMTOKENS 

♦IMPLIED 

codeword 

NMTOKENS 

♦IMPLIED 

scilevel 

%y*somo; 

"0" 

diglyph 

NMTOKENS 

♦IMPLIED> 

< ! ELEMENT 

body 

-  -  (section*) > 

< ! ATTLIST 

body 

security 

(uc  1 

c  I  s  I 

♦IMPLIED 

restrict 

NMTOKENS 

♦IMPLIED 

release 

NMTOKENS 

♦IMPLIED 

codeword 

NMTOKENS 

♦IMPLIED 

scilevel 

%yesorno ; 

IIQII 

diglyph 

NMTOKENS 

♦IMPLIED> 

< ! ELEMENT 

section 

-  -  (title, 

(title?, 

< ! ATTLIST 


section 


(parataxt  |  (%spcpara;) 
|  %list ;)+)+,  fltdesc*, 
fltiso*,  (figure, 
fltproc) *) > 


♦IMPLIED 


<! ELEMENT 
< l ATTLIST 
♦REQUIRED 


inschlvl 

NUTOKEN 

♦IMPLIED 

delchlvl 

NUTOKEN 

♦IMPLIED 

label 

NMTOKEN 

♦IMPLIED 

texttype 

NUMBER 

♦  IMPLIED 

itemid 

NMTOKEN 

♦IMPLIED 

config 

NUTOKENS 

♦IMPLIED 

skilltrlc 

CDATA 

♦IMPLIED 

hep 

tyesorao ; 

WO" 

xref 

IDREF 

♦IMPLIED 

security 

(uc  |  c  |  s  j 

ts) 

♦IMPLIED 

restrict 

NMTOKENS 

♦IMPLIED 

release 

NMTOKENS 

♦IMPLIED 

codeword 

NMTOKENS 

♦IMPLIED 

scilevel 

%yesomo ; 

*•0** 

diglyph 

NMTOKENS 

♦IMPLIED> 

fltdesc  -  -  (title,  descunit+)> 

fltdesc  fltcode  CDATA 


<! ELEMENT 


security 

restrict 

release 

codeword 

scilevel 

diglyph 

deacunit 


(uc  |  c  |  s 

NMTOKENS 

NMTOKENS 

NMTOKENS 

%yesorno ; 

NMTOKENS 


♦IMPLIED 

♦IMPLIED 

♦IMPLIED 

♦IMPLIED 

#IMPLIED> 


( (# PCDATA) , descunit*) > 
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<!ATTUST 
# IMPLIED 


daacunit 


add2flt 


CDATA 


<! ELEMENT 


<  l  ATTLIST 
# REQUIRED 


< ! ELEMENT 


< ! ATTLIST 
♦REQUIRED 


<! ELEMENT 
< I  ELEMENT 

<! ATTLIST 
# IMPLIED 


< ! ELEMENT 
<! ATTLIST 


aacurity 

(uc  |  c  |  a  | 

ta)  ♦IMPLIED 

raatrict 

NMTOKENS 

♦IMPLIED 

ralaaaa 

NMTOKENS 

♦IMPLIED 

codaword 

NMTOKENS 

♦IMPLIED 

acilaval 

%yaaomo; 

NQH 

diglyph 

NMTOKENS 

#IMPLIED> 

fltiao 

-  -  (apptaqpt?,  (%apcpara;), 

cauaadby,  (taakinfo, 

((taat,  raapgrp-*-)  |  tabla))+)> 
fltiao  fltcoda  NUTOKEN 


aacurity 

raatrict 

ralaaaa 

codaword 


(uc  |  c  |  a 
NMTOKENS 
NMTOKENS 
NMTOKENS 


ta)  # IMPLIED 
♦ IMPLIED 
# IMPLIED 
# IMPLIED 


acilaval  %yaaorno;  H0(' 

diglyph  NMTOKENS  #IMPLIED> 

fltproc  -  -  (sppteqpt?,  (%spcpara;), 

cauaadby?,  (taakinfo, 

(taat,  raapgrp+) ) +) > 


fltproc  fltcoda  NUTOKEN 


sacurity 

raatrict 

ralaaaa 

codaword 

acilaval 


(uc  I  c  I 
NMTOKENS 
NMTOKENS 
NMTOKENS 
%yaaomo ; 


a  |  ta) 

»0H 


# IMPLIED 
# IMPLIED 
# IMPLIED 
# IMPLIED 


diglyph  NMTOKENS  #IMPLIED> 

apptaqpt  -  (parataxt) > 

taakinfo  -  -  (titla?,  %apcpara ; , 

(atapgrp  |  atapl)*  )> 
taakinfo  taaktypa  CDATA 


id 

ID 

inachlvl 

NUTOKEN 

dalchlvl 

NUTOKEN 

labal 

NMTOKEN 

taxttypa 

NUMBER 

itamid 

NMTOKEN 

config 

NUTOKENS 

akilltrk 

CDATA 

hep 

lyaaomo ; 

xraf 

I  DREE 

aacurity 

(uc  |  c  | 

raatrict 

NMTOKENS 

ralaaaa 

NMTOKENS 

codaword 

NMTOKENS 

acilaval 

%yaaorao  ? 

diglyph 

NMTOKENS 

♦IMPLIED 

♦IMPLIED 

♦IMPLIED 

♦IMPLIED 

♦IMPLIED 

♦IMPLIED 

♦IMPLIED 

♦IMPLIED 

|»0  " 

♦IMPLIED 

|  ta)  ♦IMPLIED 
♦IMPLIED 
♦IMPLIED 
♦IMPLIED 

"0" 

#IMPLIED> 


atapgrp  -  (stepl,  stapl+)> 

stepgrp  id  ID  # IMPLIED 

inschlvl  NUTOKEN  # IMPLIED 
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< 1  ELEMENT 
< ! ATTLIST 


stapl 

stapl 


dalchlvl 

labal 

taxttypa 

itaaid 

config 

skilltrk 

hep 

xraf 

sacurity 

rastrict 

ralaasa 

codaword 

scileval 

diglyph 


NUTOKEN 

NMTOKEN 

NUMBER 

NMTOKEN 

NUTOKENS 

CDLTA 

lyaiomo ; 

IDREF 

(ue  |  c  |  s  | 
NMTOKENS 
NMTOKENS 
NMTOKENS 
%yai*orno ; 
NMTOKENS 
*  ((tspepara 


# IMPLIED 
# IMPLIED 
# IMPLIED 
# IMPLIED 
# IMPLIED 
# IMPLIED 

«0** 

# IMPLIED 
ta)  # IMPLIED 
# IMPLIED 
♦IMPLIED 
♦IMPLIED 

*»0” 

♦IMPLIED> 

; ) , parataxt ,  step2  * ) > 


<! ELEMENT 
<! ATTLIST 


inschlvl 

NUTOKEN 

♦IMPLIED 

dalchlvl 

NUTOKEN 

♦IMPLIED 

labal 

NMTOKEN 

♦IMPLIED 

itaaid 

NMTOKEN 

♦IMPLIED 

config 

NUTOKENS 

♦IMPLIED 

skilltrk 

CDATA 

♦IMPLIED 

hep 

%yasorno ; 

"0” 

xraf 

IDREF 

♦IMPLIED 

sacurity 

(ue  1  c  I  s  j 

ts) 

♦IMPLIED 

rastrict 

NMTOKENS 

♦IMPLIED 

ralaasa 

NMTOKENS 

♦IMPLIED 

codaword 

NMTOKENS 

♦IMPLIED 

seilaval 

%yasorno ; 

|»0*» 

diglyph 

NMTOKENS 

♦IMPLIED 

ipi 

NAME 

♦IMPLIED 

parson 

NAME 

♦IMPLIED 

taxttypa 

NUMBER 

♦IMPLIED? 

stap2 

stap2  id 

inschlvl 
dalchlvl 
labal 
itaaid 
config 
skilltrk 
hep 
xraf 

sacurity 

rastrict 

ralaasa 

codaword 

acilaval 

diglyph 

ipi 

parson 

taxttypa 


( (%opcpara;) ,  parataxt,  stap3*)> 


NUTOKEN 

NUTOKEN 

NMTOKEN 

NMTOKEN 

NUTOKENS 

CDATA 

%yasomo; 

IDREF 

(ue  |  c  | 

NMTOKENS 

NMTOKENS 

NMTOKENS 

%yasorao ; 

NMTOKENS 

NAME 

NAME 

NUMBER 


♦IMPLIED 

♦IMPLIED 

♦IMPLIED 

♦IMPLIED 

♦IMPLIED 

♦IMPLIED 

♦IMPLIED 

♦IMPLIED 

♦IMPLIED 

♦IMPLIED 

♦IMPLIED 

♦IMPLIED 

♦IMPLIED 

♦IMPLIED 

♦IMPLIED 

♦IMPLIED? 


< l ELEMENT 
< ! ATTLIST 


< ! ELEMENT 
<! ELEMENT 
<! ATTLIST 


< ! ELEMENT 
<i ATTLIST 


stap3 

stap3 


( ( tspcpara ; ) ,  paratext ) > 


♦IMPLIED 


inschlvl 

NUTOKEN 

♦IMPLIED 

delchlvl 

NUTOKEN 

♦IMPLIED 

label 

NMTOKEN 

♦IMPLIED 

itenid 

NMTOKEN 

♦IMPLIED 

config 

NUTOKENS 

♦IMPLIED 

skilltrk 

CDATA 

♦IMPLIED 

hep 

%yesorno; 

"0" 

xref 

IDREF 

♦IMPLIED 

security 

(uc  |  c  |  s  | 

ts) 

♦IMPLIED 

restrict 

NMTOKENS 

♦IMPLIED 

release 

NMTOKENS 

♦IMPLIED 

codeword 

NMTOKENS 

♦IMPLIED 

scilevel 

%yesorno; 

mq*» 

diglyph 

NMTOKENS 

♦IMPLIED 

ipi 

NAME 

♦IMPLIED 

person 

NAME 

♦IMPLIED 

texttype 

NUMBER 

♦IMPLIED> 

test 

response 


( # PCDATA,  response*) > 
EMPTY> 


response  rsvpval  CDATA 


rsvpref 

xref 


IDREP 

IDREF 


♦REQUIRED 

#IMPLIED> 


respgrp 

respgrp 


(taskinfo,  (test  |  table) ?)> 

#REQUIRED> 


< l ELEMENT 
<! ATTLIST 
♦IMPLIED 


<! ELEMENT 
<! ATTLIST 
♦IMPLIED 


figindex  -  -  (#PCDATA)> 

figindex  security  (uc  |  c  |  s  |  ts) 


restrict  NMTOKENS 


release 


NMTOKENS 


codeword  NMTOKENS 
scilevel  %yesorno; 


diglyph 

docno 

docno 


NMTOKENS 

-  (♦PCDATA) > 

security  (uc 


♦IMPLIED 

♦IMPLIED 

♦IMPLIED 

♦IMPLIED> 


restrict 

NMTOKENS 

♦IMPLIED 

release 

NMTOKENS 

♦IMPLIED 

codeword 

NMTOKENS 

♦IMPLIED 

scilevel 

diglyph 

lyesorno;  "0" 

NMTOKENS 

♦IMPLIED> 

< ! ELEMENT 

sssn 

-  ( ♦PCDATA) > 

<! ATTLIST 

sssn 

security  (uc  | 

c  |  s  | 

♦IMPLIED 

restrict 

NMTOKENS 

♦IMPLIED 

release 

NMTOKENS 

♦IMPLIED 

codeword 

NMTOKENS 

♦IMPLIED 

scilevel 

lyesorrio?  "O” 
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<1 ELEMENT 
< ! ATTLIST 
* IMPLIED 


<! ELEMENT 
< i ATTLIST 
# IMPLIED 


< ! ELEMENT 
<! ATTLIST 
♦ IMPLIED 


< !  elek:,.,  r 

<! ATTLIST 
# IMPLIED 


<! ELEMENT 
<! ATTLIST 
# IMPLIED 


< ! ELEMENT 
< ! ATTLIST 
# IMPLIED 


< ! ELEMENT 


diglyph  NMTOKENS  #IMPLIED> 

tool  -  -  (#PCDATA) > 

tool  security  (uc  |  c  |  i  |  ts) 


restrict 

release 

codeword 
sell aval 


diglyph 
testeq 
■  tastaq 


NMTOKENS 

NMTOKENS 

NMTOKENS 

lyasorno;  "0" 

NMTOKENS 

-  “  (# PCDATA) > 

security  (uc  | 


♦IMPLIED 

♦IMPLIED 

♦IMPLIED 

♦  l'4PLIED> 

c  |  s  |  ts) 


restrict 

release 

codeword 

scilevel 

diglyph 

material 

material 


NMTOKENS 

NMTOKENS 

NMTOKENS 

%yesomo;  *»o" 

NMTOKENS 

-  “  (# PCDATA) > 

security  (uc  | 


♦IMPLIED 

♦IMPLIED 

♦IMPLIED 

#IMPLIED> 

C  |  s  j  ts) 


restrict 

release 

codeword 

scilevel 

diglyph 

torquevl 

torquevl 


NMTOKENS 

NMTOKENS 

NMTOKENS 

%yesorno;  "o" 

NMTOKENS 

-  -  ( # PCDATA) > 

security  (uc  | 


♦IMPLIED 

♦IMPLIED 

♦IMPLIED 

♦IMPLIED> 

c  |  S  |  ts) 


restrict 

release 

codeword 

scilevel 

diglyph 


NMTOKENS 

NMTOKENS 

NMTOKENS 

%yesomo 

NMTOKENS 


stchg  -  o  EMPTY> 

stchg  level  NUMBER 


*»0" 


♦IMPLIED 

♦IMPLIED 

♦IMPLIED 

♦IMPLIED> 


s-atus  (add  |  delete)  ♦IMPLIED 

security  (uc  |  c  |  s  |  ts)  # IMPLIED 

restrict  NMTOKENS  ♦IMPLIED 

release  NMTOKENS  ♦IMPLIED 

codeword  NMTOKENS  ♦IMPLIED 

scilevel  %yesorno;  ••0" 

diglyph  NMTOKENS  ♦IMPLIED> 

endchg  -  o  EMPTY > 


endchg  level  NUMBER 


status 

security 

restrict 

release 

codeword 

scilevel 

diglyph 

subserpt 


(add  |  delete) 

(uc  |  c  j  s  | 

NMTOKENS 

NMTOKENS 

NMTOKENS 

%yesorno? 

NMTOKENS 

(♦PCDATA, 


♦IMPLIED 
ts)  ♦IMPLIED 
♦IMPLIED 
♦IMPLIED 
♦IMPLIED 

"0" 

♦IMPLIED> 
subserpt? , 
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supscrpt?) > 

< 1 ATTLIST 

subscrpt 

security 

(uc  | 

c  I  s  I  ts) 

# IMPLIED 

restrict 

NKTOKENS 

#  IMPLIED 

release 

NMTOKENS 

# IMPLIED 

codeword 

NMTOKENS 

# IMPLIED 

scilevel 

tyesomo ; 

II  QH 

diglyph 

NMTOKENS 

#IMPLIED> 

< ! ELEMENT 

supscrpt 

-  -•  (#  PCDATA 

,  subscrpt?, 

supscrpt?) > 

< I ATTLIST 

supscrpt 

security 

(uc  | 

c  |  s  |  ts) 

# IMPLIED 

restrict 

NMTOKENS 

# IMPLIED 

release 

NMTOKENS 

# IMPLIED 

codeword 

NMTOKENS 

IIMPLIED 

scilevel 

tyesomo ; 

"O'* 

diglyph 

NMTOKENS 

#IMPLIED> 

< ! ELEMENT 

conf ig 

-  o  EMPTY> 

<! ATTLIST 

config  code  CDATA 

IREQUIRED 

security 

(uc  I  c  I  s  I 

ts) 

#IMPLIED 

restrict 

NMTOKENS 

IIMPLIED 

release 

NMTOKENS 

IIMPLIED 

codeword 

NMTOKENS 

IIMPLIED 

scilevel 

%yesorno; 

"0" 

diglyph 

NMTOKENS 

|IMPLIED> 

< ! ELEMENT 

xref 

-  o  EMPTY > 

<! ATTLIST 

xref  xref  CDATA 

#REQUIRED 

security 

(uc  |  c  |  s  | 

ts) 

IIMPLIED 

restrict 

NMTOKENS 

IIMPLIED 

release 

NMTOKENS 

IIMPLIED 

codeword 

NMTOKENS 

IIMPLIED 

scilevel 

tyesomo ; 

"0" 

diglyph 

NMTOKENS 

IIMPLIED> 

<! ELEMENT 

graphic 

-  o  EMPTY > 

<! ATTLIST 

graphic  boardno  CDATA 

#REQUIRED 

width 

NUTOKEN 

IIMPLIED 

depth 

NUTOKEN 

IIMPLIED 

window 

CDATA 

IIMPLIED 

hscale 

NUTOKEN 

IIMPLIED 

vseale 

NUTOKEN 

IIMPLIED 

text 

CDATA 

IIMPLIED 

rotation 

NUMBER 

iiqm 

security 

(UC  |  c  |  s  | 

ts) 

IIMPLIED 

restrict 

NMTOKENS 

IIMPLIED 

release 

NMTOKENS 

IIMPLIED 

codeword 

NMTOKENS 

IIMPLIED 

scilevel 

tyesomo ; 

"0" 

diglyph 

NMTOKENS 

#IMPLIED> 

<1  ELEMENT 

partno 

-  (# PCDATA )> 

<! ATTLIST 

partno 

security 

(uc  1 

c  |  s  |  ts) 

# IMPLIED 
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restrict 

NMTOKENS 

# IMPLIED 

release 

NMTOKENS 

# IMPLIED 

codeword 

NMTOKENS 

IIMPLIED 

scilevel 

tyesorno ; 

"C" 

diglyph 

NMTOKENS 

#IMPLIED> 

<1ELEMENT 

model no 

-  (I PCDATA) > 

<! ATTLIST 

modelno 

security 

(uc  | 

c  |  s  | 

# IMPLIED 

restrict 

NMTOKENS 

# IMPLIED 

release 

NMTOKENS 

♦IMPLIED 

codeword 

NMTOKENS 

IIMPLIED 

scilevel 

%yesorno ; 

HQ" 

diglyph 

NMTOKENS 

#IMPLIED> 

< ! ELEMENT 

warning 

-  -  (graphic?,  (paratext) )> 

<! ATTLIST 

warning  name 

ENTITY 

type 

NAME 

IIMPLIED 

xref 

IDREF 

IIMPLIED 

vital 

(y  f  n) 

"n" 

security 

(uc  I  c  I 

s  |  ts) 

IIMPLIED 

restrict 

NMTOKENS 

IIMPLIED 

release 

NMTOKENS 

IIMPLIED 

codeword 

NMTOKENS 

IIMPLIED 

scilevel 

%yesorno ; 

"0" 

diglyph  NMTOKENS  #IMPLIED> 

<! ELEMENT  caution  -  -  (graphic?,  (paratext) ) > 

< ! ATTLIST  caution  nama  ENTITY 


fcrNREF 


#CHEEF 


typa  NAME  I  IMPLIED 

xraf  IDREF  # IMPLIED 

sacurity  (uc  |  c  |  a  |  ts)  # IMPLIED 

restrict  NMTOKENS  # IMPLIED 

release  NMTOKENS  I IMPLIED 

codeword  NMTOKENS  # IMPLIED 

scilevel  %yesomo;  "O'* 

diglyph  NMTOKENS  #IMPLIED> 

<! ELEMENT  note  -  -  (graphic?,  (paratext) )> 

<!  ATTLIST  note  name  ENTITY  #XNFEF 


type  NAME  #  IMPLIED 

xraf  IDREF  I IMPLIED 

security  (uc  (  c  |  s  |  ts)  IIMPLIED 

restrict  NMTOKENS  # IMPLIED 

release  NMTOKENS  # IMPLIED 

codeword  NMTOKENS  I IMPLIED 

scilevel  tyesomo;  "0" 

diglyph  NMTOKENS  #IMPLIED> 


<1  ELEMENT 

stemg 

-  o 

EMPTY> 

<! ELEMENT 

endemg 

-  o 

EMPTY> 

<! ELEMENT 

stemph 

-  o 

EMPTY > 

<1 ATTLIST 

stemph 

type 

NUMBER 

♦REQUIRED 

> 

< ! ELEMENT 

endemph 

-  o 

EKPTY> 

<1 ATTLIST 

endemph 

type 

NUMBER 

101 


Fault  Iaolatlon  Manual  DTP 

# REQUIRED  > 

3> 


APPENDIX  D 


INTERMEDIATE  MAINTENANCE  DESTRUCTIONS 
DOCUMENT  TYPE  DEFINITION 


103 


< i DOCTYPE 
<! ENTITY 
< ! ENTITY 


< l ENTITY 


<1  ENTITY 
<! ENTITY 

< ! ENTITY 
> 

< ! ENTITY 


< 1  ENTITY 

< ! ENTITY 
< l ENTITY 


taiai  [ 

:  yuomo  "NUMBER"  > 


bodyatt  " id 
inschlvl 
delchlvl 
label 
texttype 
iLemid 
conf ig 
sJcilltrk 
hep 
xref 


10 

NUTOKEN 

NUTOKEN 

NMTOKEN 

NUMBER 

NMTOKEN 

NUTOKENS 

CDATA 

tyesorno;  *0' 
IDREF 


# IMPLIED 
♦IMPLIED 
♦IMPLIED 

♦IMPLIED 

♦IMPLIED 

♦IMPLIED 

♦IMPLIED 

♦IMPLIED 

♦IMPLIED"  > 


colfmt  "colnum 

datatype  CDATA 


NUMBER  # REQUIRED 

♦IMPLIED 


left 

right 

center 

char 

width 

leader 

colsep 

rowhead 


%yesorno;  ‘O' 
%yesorno 
%yesorno 

CDATA 

NUMBER 

CDATA 

%yesomo 

tytsomo 


•o' 

•o' 

♦IMPLIED 

♦IMPLIED 
♦IMPLIED 
♦IMPLIED 
•  O'  " 


> 


contdef  "TBD"  > 
def  ""  > 


%  list 


"seqlist  |  randlist  |  deflist" 


%  secur  "security  (uc  |  c  | 

s  I  ts)  ♦IMPLIED 
restrict  NMTOKENS  ♦IMPLIED 
release  NMTOKENS  ♦IMPLIED 

codeword  NMTOKENS  ♦IMPLIED 
scilevel  %yesorno  • 0 ' 
diglyph  NMTOKENS  ♦IMPLIED"  > 

%  spepara  "(warning*,  caution*,  note*)"  > 

%  change  "stchg  I  endchg"  > 

%  asyntxt  "stemg  |  endemg  |  % change?  | 
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*  A  A  »  A  *  A  A 


stemph  |  endemph  |  con fig"  > 

<1  ENTITY  %  nums  "partno  |  modelno  |  sssn  |  figindex" 

> 

<! ENTITY  %  text  "%asyntxt;  | 

%nums;  |  tool  |  testeq  | 
material  |  torquevl  | 
xref  |  graphic  | 

subscrpt  j  supscrpt"  > 

<  1 

***************************************************************** 
— > 

! —  End  Entities  — > 

**************************************************************** 

— > 


**************************************************************** 

— > 

! —  Definitions  of  Elements  and  their  Attributes  — > 

i  _ 

**************************************************************** 

--> 


<! ELEMENT  tmimi  -  -  (front,  body)  > 

<j — ELENOTE  tmimi  Technical  Manual  :  Intermidiate 

Maintenance  Instructions  — > 


< 1 ATTLIST  tmimi 


<!—  ATTNOTE  tmimi 


"formal" 

NUMBER 

NUMBER 


"0" 

HQH 


status  (revision 

change  I 
prelim  | 
draft  | 
formal) 
revno 
chgno 

%secur?  > 

status  "This  is  the  status  of  the 

document  at  the  time  of 
composition,  and  is  usually 
reflected  on  the  title  page." 
revno  "Revision  number  of  the  doc." 

chgno  "Change  ltjvel  of  the  document." 

%secur;  "defined  in  entities  — > 


<1  ELEMENT  front  -  -  (idinfo, 

1«P, 


verstat? , 
contents , 
loi,  lot, 


intro?)  > 

< ! ATTLIST 

front 

%secur; 

> 

< 1  ELEMENT 

idinfo 

-  -  (pubno+, 

prepubno?, 

%spcpara; , 
titleblk, 

(mfr,  contrno)+, 
docmfr?, 
notice-*-, 
pubdate, 

chgdate?)  > 

<! ATTLIST 

idinfo 

%secur; 

> 

< ! ELEMENT 

pubno 

-  (user,  docno) 

> 

<! ATTLIST 

pubno 

%secur; 

> 

- 

< ! ELEMENT 

prepubno 

"  ®  (user,  docno) 

> 

<! ATTLIST 

prepubno 

%secur  ; 

> 

<1 ELEMENT 

user 

-  (# PCDATA)  > 

<! ATTLIST 

user 

%secur ; 

> 

<! ELEMENT 

titleblk 

-  -  (doctype, 

maintlvl*, 

prtitle)  > 

I 

< ! ATTLIST 

titleblk 

%secur; 

> 
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<1 ELEMENT  doctype  -  - 

<1 ATTLIST  doctype  %secur? 


(#PCDATA)  + ( %  text ; )  > 


> 


< ! ELEMENT 

maintlvl 

—  — 

(  # PC DATA)  +  ( %text ; ) 

<1 ATTLIST 

maintlvl 

%secur ; 

> 

< ! ELEMENT 

sssnrng 

-  - 

(# PCDATA)  +(%text; ) 

<! ATTLIST 

sssnrng 

%secur; 

> 

< ! ELEMENT 

prtitle 

-  - 

(nomen,  type?) 

> 

<! ATTLIST 

prtitle 

%sacur; 

> 

<1 ELEMENT 

nomen 

-  - 

( # PCDATA) 

> 

< I ATTLIST 

nomen 

%secur; 

<! ELEMENT 

typedea 

-  - 

(♦PCDATA) 

> 

<J ATTLIST 

typedes 

%secur; 

> 

<! ELEMENT 

altdes 

— 

(♦PCDATA) 

> 

<! ATTLIST 

altdes 

%secur; 

> 

<1 ELEMENT 

use 

-  - 

( # PC DATA) 

> 

<! ATTLIST 

use 

%secur; 

> 

<! ELEMENT 

specs 

-  - 

(♦PCDATA) 

> 

<1 ATTLIST 

specs 

%secur ; 

<! ELEMENT 

type 

-  - 

(♦PCDATA) 

> 

<!ATTLIST  type 

%secur ; 

> 

<1  ELEMENT  charac 

— 

(parat) 

> 

<! ATTLIST  charac 

%secur; 

> 

<! ELEMENT  geninfo 

— 

(para+) 

> 

< ! ATTLIST  ganinfo 

%secur ? 

> 

<! ELEMENT  purpose 

— 

(para+) 

> 

<! ATTLIST  purpose 

%secur; 

> 

<! ELEMENT  factdata 

-  - 

(para+) 

> 

<! ATTLIST  factdata 

%secur ; 

> 

<! ELEMENT  rafr 

-  - 

(# PCDATA) 

> 

<1 ATTLIST  mfr 

%sacur; 

> 

<! ELEMENT  docmfr 

-  - 

x# PCDATA) 

> 

<! ATTLIST  docrofr 

%secur; 

> 

<1  ELEMENT  contrao 

— 

(# PCDATA) 

> 

<! ATTLIST  contrno 

tsecur ; 

> 

<! ELEMENT  notice 

-  ( {# PCDATA)  J 

(%list ; ) ) *  + ( %text ; ) 

> 

<! ATTLIST  notice 

type  (dist  1 

auth  | 
off  ic 
branch 
pgclass 
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disci  \ 
super sad | 

•ffdats 
suppl 
nopg  | 

noclaspg)  #IMPLIED 
%secur;  > 


<! ELEMENT  pubdate 

-  - 

(# PCDATA) 

> 

<: ATTLIST  pubdate 

%secur; 

> 

<! ELEMENT  chgdate 

-  - 

(# PCDATA) 

> 

< I ATTLIST  chgdate 

%secur; 

> 

<! ELEMENT  data 

-  - 

(# PCDATA) 

> 

< I ATTLIST  date 

tsecur; 

> 

<! ELEMENT  lap 

-  o 

EMPTY 

> 

<! ELEMENT  loi 

-  o 

EMPTY 

> 

<1  ELEMENT  lot 

-  o 

EMPTY 

> 

<1  ELEMENT  verstat 

-  - 

(para, 

(para  | 

%list;  | 

%spcpara; ) *) 

> 

< ! ATTLIST  veratat  %secur?  > 


<! ELEMENT  contents  -  o  EMPTY 


> 


109 


<1  ELEMENT  intro 


(title, 


(title?, 

(para  | 
abbraact  | 
aymaect  I 
tctorac  [ 

(%liat; )  )+  )+  )  > 

<!ATTLIST  intro  %aecur; 


<! ELEMENT  seqlist  -  - 

< ! ATTLIST  saqlist  labal 

%s«cur; 

<! ELEMENT  randlist  - 

<! ATTLIST  randlist  %secur; 

<! ELEMENT  dafliat  -  - 

<! ATTLIST  dafliat  %aecur; 

< ! ELEMENT  item  - 

< l ATTLIST  item  %bodyatt ; 

%aecur; 

<! ELEMENT  symaect  -  - 

<! ATTLIST  symsect  %secur; 

< l ELEMENT  abbraact  - 

< l ATTLIST  abbraact  %aacur; 


(title?,  item*)  > 

CDATA  # IMPLIED 

> 

(title?,  item*)  > 

> 

(term,  def)+  > 

> 

( # PCDATA)  +(%texty)  > 

> 

(deflist)  > 

> 

(defliat)  > 

> 
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<1  ELEMENT  term  -  - 

< ! ATTLIST  term  %secur; 


( # PCDATA)  + ( %  text ; )  > 


<! ELEMENT  tctorec 


(pubno, 
title, 
date?) + 


<1 ATTLIST  tctorec  %«ecur; 


<! ELEMENT  title 


(# PCDATA)  + ( %text ; ) 


<! ATTLIST  title  %secur; 

texttype  NUMBER 


# IMPLIED  > 


<! ELEMENT  daf 


<1 ATTLIST  def 


( { # PCDATA)  | 

table) +  »(%list?) 

+ ( %text ; )  > 


%*ecur; 


<1  ELEMENT  para 


(title?, 
(# PCDATA) , 
(%list ;  | 
%»popara?) *)+ 


+(%text;)  > 


<! ATTLIST  para  %bodyatt; 

%secur; 


<1  ELEMENT  chart 


<! ATTLIST  chart 


-  (  title, 

(  tabdef  | 
stdtable  ) ,  . 
thead? , 
tbody  ) 

%bodyatt ; 
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%aecur; 


> 


<! ELEMENT  table 


< ! ATTLIST  table 

%secur; 


-  (title, 

(tabdef  | 
stdtable) , 
thead?, 

tbody)  + (warning  | 

caution  | 
note)  > 

%bodyatt; 

> 


<! ELEMENT  stdtable  -  o  EMPTY 

<! ATTLIST  stdtable  name  ENTITY  IREQUIRED 

lizeour;  .  > 


<! ELEMENT  tabdef  -  - 

<! ATTLIST  tabdef  siderule 

colsep 
rowsep 
orient 
width 
%secur; 


(colbddef)*  > 

%yesorno;  "0" 

%yesorno;  "0" 

%yesorno;  "0" 

(port  land)  "port" 

(page  column)  "page" 

> 


<1  ELEMENT  colbddef  -  o  EMPTY 

<! ATTLIST  colbddef  %colfmt; 

<i ELEMENT  thead  -  -  (row+) 

<! ATTLIST  thead  %secur* 

<! ELEMENT  tbody  -  -  (row+) 
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%secur; 


> 
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<!ATTLIST  tbody 


< ! ELEMENT 

row  -  -  (entry*) 

> 

< ! ATTLIST 

row  number  NUMBER 

rowsep  %yesorno;  #IMPLIED 

♦REQUIRED 

%secur; 

> 

< ! ELEMENT 

entrY  -  -  ( # PCDATA)  -(figure  1 

table  | 
chart) 

+ ( %text ; )  > 

■ 

<! ATTLIST 

entry  col  NUTOKEN 

row  NMTOKEN  # CURRENT 

rotate  -  '  NUMBER  "O” 

♦REQUIRED 

%secur ; 

> 

<! ELEMENT 

figure  -  -  (graphic*, 

title, 

legend?)  > 

<! ATTLIST  figure  %bodyatt; 

%secur; 

> 

<! ELEMENT 

legend  -  -  (deflist) 

> 

<! ATTLIST 

legend  %secur; 

> 

< ! ELEMENT 

body  -  -  (descsect, 

toolsect , 
theory? , 
tiein?, 
prepsect? , 
chkoutsect? , 
section*, 

ipb)  > 
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<1—  The  body  of  an  intermediate  maintenance  instruction  sat 

should  consist  of  a  Description  and  a  Special  tool  section 
optionally  followed  by  Theory,  tiein,  preparation,  and  check 

out.  These  optinal  sections  will  be  followed  by  one  or 
more  setions  of  maintenance  instructions,  and  an  Illustrated 

*  » 

Parts  Breakdown.  — > 

<!ATTLIST  body  %secur;  > 


<! ELEMENT  descsect  -  -  (geninfo,  purpose, 

factdata,  charac)  + (figure  | 
chart  | 

table)  > 

<! — ELENOTE  descsect  This  section  gives-  an  overall 

description 

of  the  system  — > 

<!ATTLIST  descsect  %secur;  > 


<! ELEMENT  toolsect  -  -  (geninfo, 

spectool , 

.  .  specegpt* , 
imprtool? , 

consume?)  +( figure  | 

chart  | 
table  )  > 

<!— ELENOTE  toolsect  This  section  is  for  special  tools, 


test  equipment,  and  consumables 

< ! ATTLIST 

toolsect 

%secur; 

> 

< ! ELEMENT 

imprtool 

-  -  (para*, 

toollist) 

> 

< ! ATTLIST 

imprtool 

%secur ; 

> 

< i ELEMENT 

spectool 

-  -  (para*, 

toollist) 

> 

<! ATTLIST 

spectool 

%secur ; 

> 

< ! ELEMENT 

toollist 

-  -  (partno, 

figindex, 

nomen , 

use)  + 

> 
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<!—  ELENOTE  toollist  This  is  a  tabular  form  list  with  the 


following  format: 
SPECIAL  TOOLS  LIST 


Part (Tool) 
Number 

Figure  & 
Index  No. 

Nomenclature 

Use 

<! ATTLIST 

toollist 

%secur; 

— > 

> 

<i ELEMENT 

speceqpt 

-  - 

(para*,  eqptlist) 

+ ( figure 

<1 ATTLIST 

speceqpt 

%secur ; 

chart  | 
table)  > 

> 

< ! ELEMENT 

eqptlist 

(typedes, 

altdes, 
fig index, 
nomen , 

use)+  > 

<! — ELENOTE  eqptlist.  This  is  a  tabular  form  list  with  the 

following  format: 

TEST  EQUIPMENT  LIST 
Alternate 

Type  Type  Figure  & 

Designation  Designation  Index  No.  Nomenclature  Use 

"*«•> 

< ! ATTLIST  eqptlist  %secur;  > 


<! ELEMENT  consume  -  -  (nomen, 

specs , 

partno)+  + (figure  | 

chart  | 
table  )  > 

<! — ELENOTE  consume  This  is  a  tabular  form  list  in  alphabetic 

order,  with  the  following  format: 

Nomenclature  Specification (s)  Part  number  and  FMSC 


*  - 

<1 ATTLIST  consume  %secur;  > 


<! ELEMENT  theory  -  -  (para+)  + (figure  | 

chart  | 
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table)  > 

<1 — ELENOTE  theory  This  section  describes  the  theory 

of  operation  of  the  equipment  and 

accessories  — > 

< 1 ATTLIST  theory  %bodyatt; 

%secur?  > 


<1 ELEMENT  tiein  -  -  (para+)  + (figure  | 

chart  | 

table)  > 

< !  —"ELENOTE  tiein  This  section  describes  the  system 

tiein  of  equipment  and  accessories  — > 

< ! ATTLIST  tiein  %bodyatt ; 

%secur; 


<! ELEMENT  prepsect  -  -  (gen info, 

(para  |  taskinfo)+  ) 
chart  | 
table) 

<! — ELENOTE  prepsect  This  section 

illustrates 

the  procedures  to  uncrate  and  unpack 
the  equipment  for  intermidiate  maint. 

— > 

< l ATTLIST  prepsect  %bodyatt; 

%secur ;  > 


♦(figure  | 


describes 


<! ELEMENT  chkoutsect  -  -  (geninfo, 

(para  |  taskinfo  j 
subsect) +  )  + (figure  | 

chart  | 

table)  > 

<!— ELENOTE  chkoutsect  This  section  contains  steps  for 

performance  testing  and  locating 
and  identifying  malfunctions  — > 

<! ATTLIST  chkoutsect  %bodyatt? 

%secur;  > 


<1 ELEMENT  section  -  (title, 

subsectt  )  +(figure  | 

chart  | 
table)  > 

< ! — ELENOTE  section  "These  are  sections  which  describe 

and  procedurally  detail  tasks  involved 


and 
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in  aaintananca  and  rapair  — > 

<1 ATT LI ST  aaction  tbodyatt; 

%sacur;  > 


<! ELEMENT  ipb  -  o  EMPTY  > 

<1 —  put  in  tha  IPB  definition  wa  came  up  with  before 
— > 

<j — ELENOTE  ipb  This  section  consists  of  a  Illustrated 

Parts  Breakdown  in  accordance  with 
MIL-M-38807.  — > 


<! ELEMENT  subsect  -  -  (title, 

para+, 

taskinfo*, 

para*  )  > 

< ! ATTLIST  subsect  %bodyatt; 

%secur;  > 


<! ELEMENT  taskinfo  -  -  (title?, 

(para | 

stepl) +)  > 

<! ATTLIST  taskinfo  tbodyatt; 

%secur;  > 


<! ELEMENT  stepl 


< 


ATTLIST  Stepl 


%secur ; 
ipi 

person 


-  -  ( (%spcpara?) , 

(fPCDATA) , 

step2*)  + (figure  j 
%text ; )  > 

tbodyatt ; 

NAME  # IMPLIED 

NAME  # IMPLIED  > 


<! ELEMENT  Step2 


<! ATTLIST  Step2 

tsecur ; 


ipi 


-  -  ( (tspcpara?) , 

(# PCDATA) , 

(step3)*)  +(%t©xt;)  > 
tbodyatt ; 

NAME  # IMPLIED 
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parson 


NAME 


# IMPLIED  > 


<! ELEMENT  step3 


-  ( ( ispcpara ? ) , 

( # PCDATA) )  + ( %text ; )  > 


< ! ATTLIST  Step3 


Isecur; 

ipi 

person 


%bodyatt; 

NAME  # IMPLIED 

NAME  # IMPLIED  > 


<! ELEMENT  docno 


(# PCDATA)  > 


<! ATTLIST  docno 


%sacur ; 


> 


< ! ELEMENT  warning 


(graphic?, 

(para*)  )  > 


<! ATTLIST  warning  name  ENTITY  #CONREF 

type  NAME  *  IMPLIED 

xref  IDREF  # IMPLIED 

vital  (y  {  n)  "n1* 

tsecury  > 


<1 ELEMENT  caution  -  - 

< ! ATTLIST  caution  name 

type 
xref 
isecur ; 


(graphic?, 

(para*)  )  > 

ENTITY  fCONREF 

NAME  # IMPLIED 

IDREF  # IMPLIED 


<! ELEMENT  note  -  -  (graphic?, 

(para*)  )  > 

<1 ATTLIST  note  name  ENTITY  fCONREF 

type  NAME  # IMPLIED 

xref  IDREF  # IMPLIED 
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%aacur; 


<! ELEMENT 

stemg 

-  o 

El 

<! ELEMENT 

•ndemg 

-  o 

EMPTY 

< I  ELEMENT 

stemph 

-  o 

EMPTY 

<! ATTLIST 

stemph 

type 

NUMBER 

<! ELEMENT 

endemph 

-  o 

EMPTY 

<! ATTLIST 

endemph 

type 

NUMBER 

< ! ELEMENT 

conf ig 

-  o 

EMPTY 

<! ATTLIST 

config 

code 

CDATA 

%sacur; 

< ! ELEMENT 

xraf 

-  o 

EMPTY 

< I ATTLIST 

xraf 

xref 

CDATA 

EMPTY 


> 

> 


#REQUIRED  > 
# REQUIRED 


#REQUIRED 

> 


%secur; 


# REQUIRED 
> 


<! ELEMENT  graphic  -  o 

< l ATTLIST  graphic  boardno 

width 
dapth 
window 
hscale 
vscala 
text 

rotation 
%s«cur; 


EMPTY 

CDATA 

NUTOKEN 

NUTOKEN 

CDATA 

NUTOKEN 

NUTOKEN 


CDATA 

NUMBER 


IREQUIRED 
# IMPLIED 
# IMPLIED 
# IMPLIED 
* IMPLIED 
# IMPLIED 
# IMPLIED 
"0" 

> 


<! ELEMENT  tool 
<! ATTLIST  tool 


(# PCDATA) 


%secur; 


<1 ELEMENT  partno  -  -  ( #PCDATA) 

<! ATTLIST  partno  %secur; 
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A  A 


<1  ELEMENT 

modelno 

—  — 

( # PCDATA) 

> 

<! ATT LI ST 

model no 

%secur ; 

> 

< 1  ELEMENT 

sssn 

-  - 

(# PCDATA) 

> 

< ! ATTLIST 

seen 

Isecur ; 

> 

< ! ELEMENT 

f igindex 

-  - 

(# PCDATA) 

> 

<! ATTLIST 

f igindex 

%secur ; 

> 

< ! ELEMENT 

testeq 

-  - 

( # PCDATA) 

> 

<1 ATTLIST 

testeq 

%secur ? 

> 

<! ELEMENT 

material 

-  - 

(♦PCDATA) 

> 

<! ATTLIST 

material 

%secur 7 

» 

> 

' :  ELEMENT 

torquevl 

-  - 

(♦PCDATA) 

> 

<i ATTLIST 

torquavl 

%secur ; 

> 

<! ELEMENT 

stchg 

-  o 

EMPTY 

> 

<1 ATTLIST 

stchg  level 

status 
%secur; 

NUMBER 

(add  |  delete)  #IMPLIED 

> 

♦IMPLIED 

<! ELEMENT 

endchg 

-  o 

EMPTY 

> 
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< l ATT LI ST  sndchg  lsvsl 

status 
%s«cur; 


NUMBER  # IMPLIED 

(add  |  dslsts)  # IMPLIED 

> 


<! ELEMENT  subscrpt  -  -  (# PCDATA, 

subscrpt? , 
supscrpt? ) 

< ! ATTLIST  subscrpt  tsecur; 


> 


<! ELEMENT  supscrpt 
<! ATTLIST  supscrpt 


-  ( # PCDATA 

subscrpt? , 
supscrpt?) 
%sacur; 


> 


> 


]> 
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APPENDIX  E 


OVERHAUL  INSTRUCTIONS 
DOCUMENT  TYPE  DEFINITION 
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»yr 


PTP- 


<!DOCTY?£  overhaul  ( 

<!  ENTITY  %  yesomo  " NUMBER" > 


< I  ENTITY  *  bodyatt  ”id 
ir.achlvl 
dalchlvl 
labal 
texttype 
itamid 
ccnfig 


hep 

xref 


ID 

NUTOKEN 

NUTOKEN 

NMTOKEN 

NUMBER 

NMTOKEN 

NUTOKENS 


skilltrk  CDATA 


%yesorno;  *0* 
IDREF 


♦ IMPLIED 
♦ IMPLIED 
I IMPLIED 

♦IMPLIED 

♦IMPLIED 

♦IMPLIED 

♦IMPLIED 

♦IMPLIED 

♦IMPLIED"  > 


<!  ENTITY  %  coifmt  "colnum 

datatype  CDATA 
left 
right 
center 
char 
width 
leader 
colsep 
rowhead 


NUMBER 

♦IMPLIED 


♦REQUIRED 


%yesorno ;  ’O' 
%yesorno; 
%yescrno; 

CDATA 

NUMBER 

CDATA 


'O' 

•O' 

♦IMPLIED 

♦IMPLIED 

♦IMPLIED 


«yasorno ;  ♦IMPLIED 
%yosorno;  'O'  ” 


<!  ENTITY  %  contdef  "TBD”  > 


<! ENTITY  %  def 


ff  V« 


<1 ENTITY  %  list 

> 


"seqlist  |  randlist  |  ueflist" 


<! ENTITY  %  secur 


"security  (uc 
s  |  ts) 
restrict  NMTOKENS 
release 
codeword 


♦IMPLIED 
♦IMPLIED 
NMTOKENS  ♦IMPLIED 
NMTOKENS  ♦IMPLIED 


scilevel 

diglyph 


%yesorno  'O' 
NMTOKENS 


♦IMPLIED"  > 


<! ENTITY  %  spepara  "(warning*,  caution*,  note*)" 

% change;  | 


<! ENTITY  %  change 
<1  ENTITY  %  asyntxt 


"stchg 

"stemg 


endchg" 
endemg  j 
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♦  A  *  A  A  *  A 


stemph  |  endamph  |  config"  > 

<  l  ENTITY  %  nums  "partno  |  modal  no  |  saan  |  figindax" 

> 

<! ENTITY  %  taxt  "%asyntxt?  | 

%nums ;  |  tool  |  taataq  | 
matarlal  |  torquavl  | 
xraf  |  graphic  | 

aubacrpt  |  supscrpt"  > 

**************************************************************** 
— > 

! —  End  Entities  ~~> 


**************************************************************** 

--> 

<! —  Definitions  of  Elements  and  their  Attributes  --> 

<  ! 

A*****************!!********************************************** 

— > 

<! ELEMENT  overhaul  -  (front,  body)  > 

<! — ELENOTE  overhaul  Technical  Manual  :  Depot  Level 

Overhaul  Instructions  — > 

< ! ATTLIST  overhaul  status  (revision  | 

change 
prelim 
draft  | 

formal)  "formal" 

revno  NUMBER  "0" 

chgno  NUMBER  "0" 

%secur;  > 

<! — ATTNOTE  overhaul  status  "This  is  the  status  of  the 

document  at  the  time  of 
composition,  and  is  usually 
reflected  on  the  title  page." 
revno  "Revision  number  of  the  doc." 

chgno  "Change  level  of  the  document." 

%secur;  "defined  in  entities  — > 
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< l ELEMENT  front  -  (idinfo, 

lap, 

verstat? , 
contents, 
loi,  lot, 

intro?)  > 

<!ATTLIST  front  %secur;  > 


<! ELEMENT  idinfo  -  -  (pubno+, 

prepubno? , 
%spcpara; , 
titleblk, 

(mfr,  contrno)+, 
docmfr? , 
notice*, 
pubdate, 


chgdate?)  > 

< ! ATTLIST  idinfo  %secur;  > 

<! ELEMENT  pubno  -  -  (user,  docno)  > 

< l ATTLIST  pubno  %secur;  > 

<! ELEMENT  prepubno  -  -  (user,  docno)  > 

<! ATTLIST  prepubno  %secur;  > 

< ! ELEMENT  user  -  -  (# PCDATA)  > 

<! ATTLIST  user  %secur;  > 


<! ELEMENT  titleblk  -  -  (doctype, 

maintlvl*, 

prtitle)  > 
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<  1 ATTLIST  titlebllc  %secur; 

<! ELEMENT  doctype  -  -  ( # PCDATA)  +(%text;) 

<! ATTLIST  doctype  %secur; 

<1  ELEMENT  maintlvl -  (# PCDATA)  +(%text:) 

<! ATTLIST  maintlvl  %secur? 

<! ELEMENT  prtitle  -  -  (nomen,  type?) 

<! ATTLIST  prtitle  %secur; 

<! ELEMENT  nomen  -  -  ( # PC DATA) 

<! ATTLIST  nomen  %secur; 

<! ELEMENT  pteqno  -  -  (IPCDATA) 

<! ATTLIST  pteqno  %secur; 

<! ELEMENT  applic  -  -  (# PCDATA) 

<! ATTLIST  applic  %secur? 

<1  ELEMENT  component  -  -  (IPCDATA) 

<! ATTLIST  component  %secur; 

<! ELEMENT  quantity  -  -  (#PCDATA) 

<i ATTLIST  quantity  %secur? 


<1  ELEMENT  ref no 
<! ATTLIST  ref no 


Isecur ; 


(IPCDATA) 


ELEMENT 

figno 

-  - 

(# PCDATA) 

> 

ATTLIST 

f  igno 

%secur ; 

ELEMENT  descrip 

-  - 

(#  PCDATA)' 

+(%text; ) 

> 

ATTLIST 

descrip 

%secur ; 

> 

ELEMENT 

minimum 

-  - 

(# PCDATA) 

+ ( %text ; ) 

> 

ATTLIST 

minimum 

%secur  ? 

> 

ELEMENT 

maximum 

-  - 

(# PC DATA) 

+(%text; ) 

> 

ATTLIST 

maximum 

%secur; 

> 

ELEMENT 

replace 

-  - 

(# PCDATA) 

+  ( %t.ext ; ) 

> 

ATTLIST 

replace 

%secur; 

> 

ELEMENT 

type 

— 

(# PCDATA) 

> 

ATTLIST  type 

%secur; 

> 

ELEMENT 

charac 

-  - 

(para+) 

> 

ATTLIST 

charac 

%secur ; 

> 

ELEMENT 

general 

-  - 

(para+) 

> 

ATTLIST 

general 

%secur ; 

> 

ELEMENT 

purpose 

-  - 

(para+) 

> 

ATTLIST 

purpose 

%secur ; 

> 

ELEMENT 

factdata 

— 

(para+) 

> 
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<! ATT LIST  fact data  %secur;  > 

< I  ELEMENT  mfr  -  ( # PC DATA)  > 

< ! ATTLIST  mfr  %secur?  > 

<! ELEMENT  docmfr  -  -  ( # PC DATA)  > 

<! ATTLIST  docmfr  %secur;  > 

<1  ELEMENT  contrno  -  -  (# PCDATA)  > 

<! ATTLIST  contrno  %secur;  > 

<! ELEMENT  notice  -  ( ( # PCDATA)  | 

(%list;))*  +(%text;)  > 


<1 ATTLIST  notice  type  (dist  j 

auth  | 
offic 
branch 
pgclass 
disci 
supersed  j 
effdate  I 
suppl  j 
nopg  | 

noclaspg)  #IMPLIED 
%secur;  > 


<! ELEMENT  pubdate  -  -  (# PCDATA)  > 

<! ATTLIST  pubdate  %secur; 


<! ELEMENT  chgdate  -  -  (# PCDATA)  > 

<! ATTLIST  chgdate  %secur; 
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<1  ELEMENT  date  -  -  ( # PCDATA)  > 

<!ATTLIST  date  %secur;  > 


< ! ELEMENT 

lep 

-  0 

EMPTY 

< ! ELEMENT 

loi 

-  o 

EMPTY 

< ! ELEMENT 

lot 

-  o 

EMPTY 

< ! ELEMENT 

verstat 

—  — 

(para 

(para  | 

%list;  j 
(%spcpara; ) )  *) 

< ! ATTLIST  verstat  %secur; 


> 

> 

> 


<! ELEMENT  contents  -  o  EMPTY 


> 


<! ELEMENT  intro  -  -  (title, 

(title?, 

(para  | 
abbrsect  j 
syrasect  I 
tctorec  j 

(%list : )  )+  )+  )  > 

<! ATTLIST  intro  %secur? 


<! ELEMENT  seqlist  -  -  (title?,  item*) 

<!  ATTLIST  seqlist  label  '  CDATA  ff  IMPLIED 

%secur;  > 
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<! ELEMENT 

randlist 

—  — 

(title?,  item*) 

> 

< ! ATTLIST 

randlist 

%secur; 

> 

< ! ELEMENT 

deflist 

-  - 

(term,  def)+ 

> 

< ! ATTLIST 

deflist 

%secur; 

> 

< ! ELEMENT 
<! ATTLIST 

item  -  - 

item  %bodyatt; 

%secur ; 

(# PCDATA)  + ( %text ; ) 

> 

> 

< ! ELEMENT 

symsect 

-  - 

(deflist) 

> 

< ! ATTLIST 

symsect 

%aecur ; 

> 

< ! ELEMENT 

abbrsect 

-  - 

(deflist) 

> 

<! ATTLIST 

abbrsect 

%secur; 

> 

<! ELEMENT 

term 

-  - 

( # PCDATA)  + ( %text ; ) 

> 

<! ATTLIST 

term 

%secur; 

> 

< l ELEMENT 

tctorec 

title 

date? 

(pubno, 

/ 

)  + 

> 

<! ATTLIST 

tctorec 

%secur ? 

> 

< 1 ELEMENT 

title 

-  - 

(# PCDATA)  +(%text; ) 

<! ATTLIST 

title 

%secur ; 
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texttype  NUMBER 


# IMPLIED  > 


<! ELEMENT  def 


< ! ATTLIST  def 


( (# PCDATA)  | 

table) +  -(%list;) 

+(%text;)  > 


%secur; 


<! ELEMENT  para 


(title?, 

(# PCDATA) , 
(%list;  | 
(%spcpara;) ) *) + 


+(%text ; ) 


<! ATTLIST  para  %bodyatt; 

%secur ; 


<i ELEMENT  chart 


(  title, 


<J ATTLIST  chart 


%secur; 


(  tabdef  ; 
stdtable  ) , 
thead? , 
tbody  ) 

tbodyatt ; 


<1  ELEMENT  table 


<3 ATTLIST  table 


%secur ; 


-  -  (  title, 

(tabdef  j 
stdtable  ) , 
thead? , 

tbody)  + (warning 

caution  | 
note) 

%bodyatt.  t 


<! ELEMENT  stdtable  -  o 


EMPTY 
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< l ATTLXST  stdtable  name  ENTITY  # REQUIRED 

%sacur;  > 


<! ELEMENT  tabdef  -  -  (colbddef ) * 

<!ATTLIST  tabdef  siderule  %yesorno;  ,,0M 

colsep  %yesorno;  "0" 

rowsep  %yesorno;  "0" 

orient  {port  land)  "port" 

width  (page  column)  "page" 

%secur;  > 


< 1  ELEMENT 

colbddef 

-  o 

EMPTY 

> 

<! ATTLIST 

colbddef 

%colfmt; 

> 

< ! ELEMENT 

thead 

-  -  (row+) 

> 

< ! ATTLIST 

thead 

%secur ; 

> 

<! ELEMENT  tbody 

.v 

-  ((row  | 

%spcpara;)+) 

> 

<! ATTLIST 

tbody 

%secur; 

> 

<! ELEMENT 

row 

-  - 

(entry+) 

> 

< ! ATTLIST 

row  number  NUMBER 

rowsep  lyesorno;  # IMPLIED 

%secur? 

#REQUIRED 

> 

( # PCDATA)  -(figure  I 

table  | 

chart) 

+(%text;)  > 


<! ELEMENT  entry 


# REQUIRED 


Ocaft  D-LfVfl  PTQ. 


< ! ATTLIST  entry 


row 

rotate 

%secur; 


col  NUTOKEN 

NMTOKEN  # CURRENT 

NUMBER  »Q» 


<! ELEMENT  figure  -  -  (graphic*, 

title, 

legend?)  > 

< I ATTLIST  figure  %bodyatt; 

%secur?  > 


<i ELEMENT  legend  -  -  (deflist) 

<! ATTLIST  legend  %secur; 


<! ELEMENT  body  -  -  (geninfo, 

toolsect, 

disassem, 

clean, 

irr, 

assembly, 
accessor? , 
testing, 
tol,  ipb?, 

dds?)  > 

<! —  The  body  of  an  Depot  maintenance  instruction  set  should 
consist 

of  a  General  Information  section  and  a  Special  tool  section 

followed  by  a  Disassembly  Section,  Cleaning  section. 
Inspection, 

Repair  and  Replacement  Section,  Assembly  Section,  an  optional 

Accessories  section,  Testing  section,  and  Table  of  Limits 
section. 

These  sections  will  be  followed  optionally  by  an  Illustrated 
Parts  Breakdown  and  a  Difference  Data  Sheet. 
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»Q  ^  r 


.-grp. 


<!ATTLIST  body 


%secur; 


<! ELEMENT  ganinfo 

< ! — ELENOTE  ganinfo 


(general,  purpose, 
charac,  factdata)  +(figure  | 
chart  | 

table)  > 

This  section  gives  an  overall  description 


of  the  system 

<!ATTLIST  geninfo  %secur; 


<1  ELEMENT  toolsect  -  -  (geninfo, 

tooleqpt) 


i--> 


< ! — ELENOTE  toolsect 


+ ( figure) > 

This  section  is  for  special  tools  and 


test  equipment 
<!ATTLIST  toolsect  %secur; 


<! ELEMENT  tooleqpt  -  -  (pteqno, 

fig index, 
nomen )+ 


<J — ELENOTE  tooleqpt 


This  is  a  tabular  form  list  with  the 


Tool/equipment 
Part  Number 


following  format: 

SPECIAL  TOOLS  and  TEST  EQUIPMENT 


Figure  & 
Index  No. 


Nomenclature 


--> 


<!ATTLIST  tooleqpt  %secur; 


<1  ELEMENT  dlsassera  -  - 


<! ELEMENT  clean 


< ! ATTLIST  clean 


%Sf 


(general , 

subsect+)  +(figure  | 

chart  | 
table) 

-  -  (general, 

subsect+  )  + (figure 

chart  j 
table)  > 

%bodyatt ; 

> 
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<! ELEMENT  irr 


< ! ATTLIST 

< 1  ELEMENT 

<i ATTLIST 

< ! ELEMENT 


<! ATTLIST 

<i ELEMENT 


-  -  (general, 

subsect+  )  + (figure 

chart  | 
table)  > 

irr  %bodyatt ; 

%secur;  > 

assembly  -  -  (general, 

subsect+  )  + (figure 

chart  | 
table)  > 

assembly  %bodyatt; 

%secur;  > 

accessor  -  -  (disassem, 

clean, 

irr, 

assembly, 

testing  )  + (figure 

chart  | 
table)  > 

accessor  %bodyatt? 

%secur;  > 


testing 


-  -  (general, 

subsect+  )  + (figure 

chart  | 
table)  > 

<! ATTLIST  testing  %bodyatt; 

%secur;  > 


<! ELEMENT  tol 

<!— ELENOTE  tol 

<! ATTLIST  tol 


(general, 

limittbl, 

torquetbl) 


+ (figure) > 


This  section  is  for  distinction 
of  limit  points  and  lubrication 
system  — > 

%secur;  > 


<! ELEMENT  limittbl  - 


(ref no, 
figno, 
descrip, 
minimum, 
maximum, 
replace) + 
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< 1 ATTLXST  linittbl  tsvcur; 


> 


<2  ELEMENT  torquetbl  -  -  (applic, 

component , 
quantity, 

torquevl)+  > 

< ! ATTLIST  torquetbl  %secur;  > 


<! ELEMENT  ipb  -  o  EMPTY  > 

<!—  put  in  the  IPB  definition  we  came  up  with  before 
— > 

<! — ELENOTE  ipb  This  section  consists  of  a  Illustrated 

Parts  Breakdown  in  accordance  with 
MIL-M-38807. 


<! ELEMENT  dds 


<! ATTLIST  dds 


-  -  (general, 

subsectt, 
limittbl? , 

torquetbl?)  +r figure  j 

chart  j 
table)  > 

%bodyatt; 

%secur;  > 


<  1 

< ! 


ELEMENT  subsect 


ATTLIST  subsect 


-  -  (title, 

para+, 
taskinfo*, 
para*  ) 
%bodyatt ; 


%secur ; 


> 

> 


<! ELEMENT  taskinfo  -  -  (title?, 

para*, 

stepl+, 

para*  )  > 

<! ATTLIST  taskinfo  %bodyatt; 

%secur;  > 


<! ELEMENT  stepl  -  -  ( (tspcpara; ) , 

(# PCDATA), 

(step2) *, 
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Draft  D-Livl  DTD 


< I ATTLIST  stepl 


laacur; 

ipi 

person 


(%list;)?)  +(figure  | 

%text ; )  > 

%bodyatt ; 

NAME  # IMPLIED 

NAME  # IMPLIED  > 


<!  ELEMENT  Step?; 


<! ATTLIST  step2 


%secur ; 
ipi 

person 


-  -  ( (%spcpara; ) , 

(# PCDATA) , 

(step3) *, 

(%list;)?)  +(%text;)  > 

%bodyatt ; 

NAME  # IMPLIED 

NAME  # IMPLIED  > 


<! ELEMENT  step3 


-  (  (%spcpara; ) , 

(# PCDATA) , 

(%list;)?)  + (%text ; )  > 


<J ATTLIST  step3 

%secur ; 
ipi 

person 


%bodyatt? 

NAME  # IMPLIED 

NAME  # IMPLIED  > 


<! ELEMENT  docno 


( # PCDATA)  > 


<! ATTLIST  docno 


%secur; 


> 


<1  ELEMENT  warning 


(graphic?, 

(para*)  )  > 


<! ATTLIST  warning  name 
type 
xref 
vital 
tsecur; 


ENTITY  #CONREF 

NAME  # IMPLIED 

IDREF  # IMPLIED 

(y  |  n)  "n" 
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<1  ELEMENT 

caution  -  - 

(graphic?, 

'<  l  ATTLIST 

(para*)  ) 

> 

caution  nama 

ENTITY 

♦CONREF 

typa 

NAME  # IMPLIED 

xref 

IDREF  # IMPLIED 

Isecur; 

> 

<! ELEMENT  note 

-  - 

(graphic?, 

(para*)  ) 

> 

<1 ATTLIST  note 

name 

ENTITY 

#CONREF 

type 

NAME  # IMPLIED 

xref 

IDREF  # IMPLIED 

%secur ; 

> 

<1  ELEMENT  stemg 

-  o 

EMPTY 

<! ELEMENT  enderog 

-  o 

EMPTY 

> 

<! ELEMENT  stemph 
<! ATTLIST  stemph 

-  o 
type 

EMPTY 

NUMBER 

> 

# REQUIRED  > 

< 1  ELEMENT  endemph 
<! ATTLIST  endemph 

-  o 
type 

EMPTY 

NUMBER 

> 

♦REQUIRED  > 

<! ELEMENT  config 

-  o 

EMPTY 

> 

<! ATTLIST  config  code 

%secur; 

CDATA 

♦REQUIRED 

> 

<! ELEMENT  xref  -  o 

<! ATTLIST  xref  xref 

%secur; 

EMPTY 

CDATA 

> 

♦REQUIRED • 

> 

<! ELEMENT  graphic  -  o 

<1 ATTLIST  graphic  boardno 

width 

EMPTY 

CDATA 

NUTOKEN 

> 

♦REQUIRED 

♦IMPLIED 
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depth 

window 

hscale 

vscale 

taxt 


NUTOKEN 

CDATA 

NUTOKEN 

NUTOKEN 


CDATA 


rotation  NUMBER 
%sacur; 


* IMPLIED 
♦IMPLIED 
♦IMPLIED 
♦IMPLIED 
♦IMPLIED 

MQW 


<! ELEMENT  tool 
< ! ATTLIST  tool 


%secur; 


(♦PCDATA) 


< I  ELEMENT  partno  -  - 

<! ATTLIST  partno  %secur; 


(♦PCDATA) 


< l ELEMENT  modelno  - 

<! ATTLIST  modelno  %secur; 


(♦PCDATA) 


<! ELEMENT  sssn 
<! ATTLIST  sssn 


%secur; 


(♦PCDATA) 


< ! ELEMENT  figindex  -  - 
<! ATTLIST  figindex  %secur? 


( ♦PCDATA) 


< ! ELEMENT  testeq  - 

<! ATTLIST  testeq  %secur; 


(♦PCDATA) 


<! ELEMENT  material  -  - 
<! ATTLIST  material  %secur; 


(♦PCDATA) 
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BcaijUfcLiYiiJtgo, 


<1  ELEMENT  torquevl  -  -  ( # PCDATA) 

< l ATT LIST  torquevl  %secur; 


<! ELEMENT  stchg 
<! ATTLIST  stchg 


-  o 


level 


EMPTY 


NUMBER 


♦IMPLIED 


status 

%secur; 


<! ELEMENT  endchg  -  o 

<! ATTLIST  endchg  level 

status 
%secur ; 


(add  I  delete)  # IMPLIED 

> 


EMPTY  > 

NUMBER  # IMPLIED 

(add  |  delete)  #IMPLIED 


<! ELEMENT  subscrpt  -  - 


(♦PCDATA, 

subscrpt?, 

supscrpt?) 


<! ATTLIST  subscrpt  %secur; 


<i ELEMENT  supscrpt  -  -  (# PCDATA, 

subscrpt? , 
supscrpt?) 

<! ATTLIST  supscrpt  %secur; 


> 


> 


]> 

“Z 
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